window size persistence feature and SVN (or other)

This forum is for all Flare issues related to using Source Control.

window size persistence feature and SVN (or other)

Postby owenf on Thu Jun 26, 2014 9:36 am

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)
owenf
Propeller Head
 
Posts: 48
Joined: Tue Sep 01, 2009 3:41 am

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

Postby Msquared on Fri Jun 27, 2014 4:29 am

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.
Msquared
Propellus Maximus
 
Posts: 847
Joined: Mon Aug 06, 2012 10:19 am
Location: Southampton, UK

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

Postby Rona Kwestel on Mon Nov 07, 2016 1:02 pm

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.
Rona Kwestel
Sr. Propeller Head
 
Posts: 171
Joined: Wed Apr 04, 2007 11:50 am

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

Postby Msquared on Tue Nov 08, 2016 9:05 am

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.
Msquared
Propellus Maximus
 
Posts: 847
Joined: Mon Aug 06, 2012 10:19 am
Location: Southampton, UK

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

Postby Rona Kwestel on Tue Nov 08, 2016 11:00 am

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."
Rona Kwestel
Sr. Propeller Head
 
Posts: 171
Joined: Wed Apr 04, 2007 11:50 am

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

Postby SteveS on Tue Nov 08, 2016 2:21 pm

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.
SteveS
Propellus Maximus
 
Posts: 1866
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).

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

Postby KayJay on Mon Dec 12, 2016 9:29 pm

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/21652242/git-re-checkout-files-after-creating-smudge-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.
KayJay
Propeller Head
 
Posts: 21
Joined: Tue Nov 29, 2016 7:19 am

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

Postby fchapman42 on Thu May 18, 2017 8:46 am

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: 6
Joined: Thu Jul 19, 2012 12:22 pm


Return to Source Control

Who is online

Users browsing this forum: No registered users and 1 guest