Versioning of tool generated xml files

[Arne Christian Hårseth <ar...@online.no>]

The department I am working for is having problems with versioning of tool
generated xml-files in CVS. Since this file is generated from a graphical
tool it tends to change a lot causing a lot of conflicts. This can be partly
solved by locking the file when changing it but this is taking away the
"concurrent" part of CVS not making it possible for several people to change
the same file simultaniously. I belive file locking is what MS VSS uses
inherently to avoid conflicts too.

Does subversion have any improvements to help reducing such problems?
Does it support file locking?

Arne


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Versioning of tool generated xml files

[Michael Wood <mw...@its.uct.ac.za>]

On Thu, Sep 05, 2002 at 05:54:46PM -0400, Alan Shutko wrote:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
> 
> > For xml files, I'd think a custom merge-tool hook would be more
> > helpful than locking... (?)
> 
> Not necessarily... I have no idea what this tool is, but from
> experience with autogenerated HTML, I bet I know the issue.
> 
> Some programs that output HTML or XML use numbers when they make IDs
> for objects, whether they be paragraphs, anchors, pictures,
> whatever.  But they don't keep track of the ID after loading the
> file, so if you make a change, all those IDs can be renumbered.
> 
> This can result in changes across the whole file resulting from one
> change, which happened to bump the IDs.  8^(  So if two people
> changed different things, their changes still might conflict.

But if you know how it numbers the objects, it might be possible to
canonicalise them or keep track of them or make the custom xmlmerge tool
aware of this problem.

-- 
Michael Wood <mw...@its.uct.ac.za>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Versioning of tool generated xml files

[Alan Shutko <at...@acm.org>]

Karl Fogel <kf...@newton.ch.collab.net> writes:

> For xml files, I'd think a custom merge-tool hook would be more
> helpful than locking... (?)

Not necessarily... I have no idea what this tool is, but from
experience with autogenerated HTML, I bet I know the issue.

Some programs that output HTML or XML use numbers when they make IDs
for objects, whether they be paragraphs, anchors, pictures,
whatever.  But they don't keep track of the ID after loading the
file, so if you make a change, all those IDs can be renumbered.

This can result in changes across the whole file resulting from one
change, which happened to bump the IDs.  8^(  So if two people
changed different things, their changes still might conflict.

-- 
Alan Shutko <at...@acm.org> - In a variety of flavors!
Be barefoot all the way up!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Versioning of tool generated xml files

[Ben Collins-Sussman <su...@collab.net>]

"Robert Koberg" <ro...@koberg.com> writes:

> The original had one line and the dev has brought it into several
> lines. If someone edits the XML in the tool before the dev commits
> then there will always be a conflict.
> 
> Would this type of thing cause a conflict in svn? I have only dipped into
> subversion and I don't currently have a running version, but this thread
> triggered my response/question.

Subversion, like CVS, simply calls the line-based 'diff' program on
two text files.  So if this scenario caused conflicts in CVS, it will
continue to do so in Subversion.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: Versioning of tool generated xml files

[Robert Koberg <ro...@koberg.com>]

Hi,

I have a similar problem that I believe occurs because the webapp spits out XML
that is all on one line. Dev-types do not use the tool much rather they
pretty-print it and work on manually.

The original had one line and the dev has brought it into several lines. If
someone edits the XML in the tool before the dev commits then there will always
be a conflict.

Would this type of thing cause a conflict in svn? I have only dipped into
subversion and I don't currently have a running version, but this thread
triggered my response/question.

best,
-Rob



> -----Original Message-----
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: Thursday, September 05, 2002 2:20 PM
> To: Arne Christian Hårseth
> Cc: dev@subversion.tigris.org
> Subject: Re: Versioning of tool generated xml files
>
>
> Arne Christian Hårseth <ar...@online.no> writes:
> > The department I am working for is having problems with versioning of tool
> > generated xml-files in CVS. Since this file is generated from a graphical
> > tool it tends to change a lot causing a lot of conflicts. This can be partly
> > solved by locking the file when changing it but this is taking away the
> > "concurrent" part of CVS not making it possible for several people to change
> > the same file simultaniously. I belive file locking is what MS VSS uses
> > inherently to avoid conflicts too.
> >
> > Does subversion have any improvements to help reducing such problems?
> > Does it support file locking?
>
> Not yet, though locking or something equivalent will happen post 1.0.
>
> For xml files, I'd think a custom merge-tool hook would be more
> helpful than locking... (?)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Versioning of tool generated xml files

[Karl Fogel <kf...@newton.ch.collab.net>]

Arne Christian Hårseth <ar...@online.no> writes:
> The department I am working for is having problems with versioning of tool
> generated xml-files in CVS. Since this file is generated from a graphical
> tool it tends to change a lot causing a lot of conflicts. This can be partly
> solved by locking the file when changing it but this is taking away the
> "concurrent" part of CVS not making it possible for several people to change
> the same file simultaniously. I belive file locking is what MS VSS uses
> inherently to avoid conflicts too.
> 
> Does subversion have any improvements to help reducing such problems?
> Does it support file locking?

Not yet, though locking or something equivalent will happen post 1.0.

For xml files, I'd think a custom merge-tool hook would be more
helpful than locking... (?)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Versioning of tool generated xml files

[Ben Collins-Sussman <su...@collab.net>]

Arne Christian Hårseth <ar...@online.no> writes:

> The department I am working for is having problems with versioning of tool
> generated xml-files in CVS. Since this file is generated from a graphical
> tool it tends to change a lot causing a lot of conflicts. This can be partly
> solved by locking the file when changing it but this is taking away the
> "concurrent" part of CVS not making it possible for several people to change
> the same file simultaniously. I belive file locking is what MS VSS uses
> inherently to avoid conflicts too.
> 
> Does subversion have any improvements to help reducing such problems?

Not yet.  The subversion working-copy library performs a contextual
merge if it believes the file is text, or just places files
side-by-side if it thinks the file is binary.

We have plans (someday) to have the client launch 3rd-party merge
tools.  So if you mark a file with some metadata property that
indicates it's xml, some kind of xml-merge tool can be launched to
resolve the conflict.  It won't be too hard to make the client launch
merge tools;  but we're not going to be writing them.  :-)

> Does it support file locking?

Not yet.  We're still discussing designs for that.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org