window size persistence feature and SVN (or other)

This forum is for all Flare issues related to using Source Control.
Post Reply
owenf
Propeller Head
Posts: 48
Joined: Tue Sep 01, 2009 3:41 am

window size persistence feature and SVN (or other)

Post by owenf »

Hi all,

we don't often get file conflicts but we are working on each others' work more commonly now. we were sitting about, wondering about the Flare topic window size parameters eg

Code: Select all

<html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd" xml:lang="en-us" MadCap:lastBlockDepth="8" MadCap:lastHeight="2542" MadCap:lastWidth="1809">
and how if two people edit a topic simultaneously, they would always end up with a conflict there (unless they magically had matching pixel-perfect GUI setup?)
this is the kind of conflict that shouldn't need a human to resolve...

so my question is, has anyone bumped into this, and do you know if we can somehow prevent this line from conflicting?

my thoughts so far, without any real testing:
  • can you turn off the feature that remembers these window size params for next time, thus removing them from source on all files?
    if not, is there a way, perhaps svn:ignore property (is there a really granular equivalent of this?)to tell the svn client not to notice these lines?
    does the flare+svn integration somehow work around these kinds of issues?
thanks in advance,
owen

(using win7, Flare 9, moving to 10 soonish, svn 1.7.x, tortoisesvn and sliksvn)
Msquared
Propellus Maximus
Posts: 848
Joined: Mon Aug 06, 2012 10:19 am
Location: Southampton, UK

Re: window size persistence feature and SVN (or other)

Post by Msquared »

I really wish that Flare didn't embed that in the files at all. Even with a single author (me!) I often find conflicts when I merge/copy content between streams and when I inspect the differences, that's all it is. I really believe that user-specific changes, and even view-specific changes should be completely separate from content changes, and hence not stored in the topic where they cannot be distinguished from genuine content changes.

Another example of something I'd like removed from the topic content is the xref text (the stuff that may change if you do Update Cross References). That too may change for reasons that are nothing to do with a change in content. Even when the cross references are "up-to-date", they depend on the currently-selected primary target (which I think may be different for each user?), the current definition of that style in the stylesheet associated with the primary target and the current heading/bookmark text in the topic that is the target of the xref. A change in any of these followed by an Update Cross References may affect the topic content, and again, it isn't really a change in the content. The actual output for a specific target may be completely different.
Marjorie

My goal in life is to be as good a person as my dogs already think I am.
Rona Kwestel
Sr. Propeller Head
Posts: 212
Joined: Wed Apr 04, 2007 11:50 am

Re: window size persistence feature and SVN (or other)

Post by Rona Kwestel »

Did anyone ever log this as a "bug" or "feature request" with MadCap? I'm running into this issue now as well when merging files in Git, and it's a real nuisance.
Msquared
Propellus Maximus
Posts: 848
Joined: Mon Aug 06, 2012 10:19 am
Location: Southampton, UK

Re: window size persistence feature and SVN (or other)

Post by Msquared »

I did, ages ago. Perhaps you would like to add your voice too? The more voices they have, the more likely it is that something will be done about it.

As well as the two examples I mentioned (the window size and the text shown for cross references) there is a third content change that doesn't represent "real" change at all. That's the autonumbering values shown in headings and numbered lists. They too are hard-coded in your topic files, but for the stylesheet used in your primary target. When your output is generated, they are replaced with the actual values as defined in the stylesheet and medium associated with that output.

So, say you have HTML and PDF outputs, and the H1, H2 and H3 headings are numbered as 1, 1.1, 1.1.1 etc in the PDF stylesheet, and have no numbers in the HTML output. I have a PDF primary target, so my content always has embedded placeholder numbers associated with each H1, H2, H3 style. You choose to have an HTML primary target, so your content has no embedded placeholder numbers. As soon as you open a topic that I edited, the placeholder numbers will be removed, to match your primary target. I think this happens as soon as you view the topic, even if you don't explicitly edit it, unless of course, you realise that you didn't mean to make any changes to that topic and don't save it when Flare asks you if you want to save it.
Marjorie

My goal in life is to be as good a person as my dogs already think I am.
Rona Kwestel
Sr. Propeller Head
Posts: 212
Joined: Wed Apr 04, 2007 11:50 am

Re: window size persistence feature and SVN (or other)

Post by Rona Kwestel »

Wow, the forum encourages wordiness. I had to enter extra text when all I wanted to say is "Done".

"Your message contains 5 characters. The minimum number of characters you need to enter is 25."
SteveS
Senior Propellus Maximus
Posts: 2087
Joined: Tue Mar 07, 2006 5:06 pm
Location: Adelaide, far side of the world ( 34°56'0.78\"S 138°46'44.28\"E).
Contact:

Re: window size persistence feature and SVN (or other)

Post by SteveS »

Rona Kwestel wrote:Wow, the forum encourages wordiness. I had to enter extra text when all I wanted to say is "Done".

"Your message contains 5 characters. The minimum number of characters you need to enter is 25."
Yes, part of the precautions against spammers...
Image
Steve
Life's too short for bad coffee, bad chocolate, and bad red wine.
KayJay
Propeller Head
Posts: 23
Joined: Tue Nov 29, 2016 7:19 am

Re: window size persistence feature and SVN (or other)

Post by KayJay »

I've been looking at the window size features lately too, and am trying to implement clean and smudge filters with git so that these values are removed when checking files in or out.
To do this, define a filter in your local .git/config file for the repo (you need to copy it there manually) by adding the lines:

Code: Select all

[filter "ignoremcheaderattrs"]
	smudge = sed \"s/\\sMadCap:\\(lastBlockDepth\\|lastHeight\\|lastWidth\\)=\\\"[0-9]*\\\"//g\"
	clean = sed \"s/\\sMadCap:\\(lastBlockDepth\\|lastHeight\\|lastWidth\\)=\\\"[0-9]*\\\"//g\"
And add the following lines to the .gitattributes file to target the files that MadCap flare changes.

Code: Select all

*.htm filter=ignoremcheaderattrs
*.flsnp filter=ignoremcheaderatts
You can run this to clean an existing repo too, see http://stackoverflow.com/questions/2165 ... dge-filter.

It's not working seamlessly yet (somehow I'm still having conflicts in one branch I'm working on) but it might be some way to a solution.
fchapman42
Jr. Propeller Head
Posts: 9
Joined: Thu Jul 19, 2012 12:22 pm

Re: window size persistence feature and SVN (or other)

Post by fchapman42 »

KayJay - thank you so much for posting your workaround for this bug in Flare.

One of the developers at my company has just helped us set this up and it looks as if it''s the answer to my prayers. We had to make some small changes to the Sed commands to get it working, but otherwise it looks as if it will work brilliantly.

We ended up adding the following lines to our Git .config file:

Code: Select all

[filter "ignoremcheaderattrs"]
   clean = sed 's/\\sMadCap:\\(lastBlockDepth\\|lastHeight\\|lastWidth\\)=\"[0-9]*\"//g'
   smudge = sed 's/\\sMadCap:\\(lastBlockDepth\\|lastHeight\\|lastWidth\\)=\"[0-9]*\"//g'
It's virtually the same, but uses single quotes around the whole command and fewer slashes before [0-9]. We're using a Git Bash shell on Windows 10.
fchapman42
Jr. Propeller Head
Posts: 9
Joined: Thu Jul 19, 2012 12:22 pm

Re: window size persistence feature and SVN (or other)

Post by fchapman42 »

Update

We've been using this filter successfully for nearly three years but recently I had a problem where I was unable to merge, rebase or cherry-pick in Git. After a lot of head scratching and lost sleep, it turned out that this filter is now causing me problems. For now I'm working around it by commenting out the filter before starting to merge, rebase or cherry-pick. If I come up with a better solution I'll post it in case anyone else is affected.

The error I've been seeing is:

Code: Select all

$ git merge branch-name
Performing inexact rename detection: 100% (2976445/2976445), done.
error: add_cacheinfo failed to refresh for path 'documentation/help/my-FlareProject/Content/topic-name.html'; merge aborting.
After the merge aborts, you're left with a branch that contains most of the files that you were expecting to get with the merge. I don't know if this is due to a recent update in Git or some other problem.
Post Reply