[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to treat XML files checked into CVS

From: Paul Sander
Subject: Re: How to treat XML files checked into CVS
Date: Tue, 15 Apr 2008 18:32:05 -0700

On Apr 15, 2008, at 5:40 PM, Arthur Barrett wrote:

Hmmmm.  I should have qualified my question:  Are such tools widely
available on all of the platforms on which users are likely
to run CVS?

I imagine so, I know Ive used similar tools to WinMerge on Linux,
Solaris and Mac OS X.  On Solaris and Linux they tend to be Java based.

If the answer is "yes" then there might be an argument to reopen the
topic of representing file types in the repository, and applying the
proper merge tools for the types of data.

Yes we've experimented with storing mime types in CVSNT repositories,
and I believe that EVSCM (previously CVSNT 3.x) has taken that further.

Setting of an 'external' app to perform the merge is a very complex (not
to mention messy) proposition, better handled by a GUI than by CVS
itself I think.

I had a long threaded discussion with the WinMerge developers some time
ago and they kept wanting us to write a CVS plugin for WinMerge and I
couldn't see the point. Either I use 'cvs up -j' to have CVSNT do the
merge for me, or I use TortoiseCVS to bring up a side by side view of
two versions and do the merge manually.

The WinMerge developers had been using CVS as their repository (on
sourceforge) for years and years and didn't even know that you could do
an automatic merge 'cvs up -j', and (perhaps understandably) had/have a
merge tool centric mindset.

They wanted to be able to pull up two versions from within the merge
tool and merge and commit. They already have plugins for most SCM tools
(including clearcase) but not CVS.

This is  a long winded way of saying that if people have complex merge
tools then I think it is unlikely they want CVS to call that merge tool
during 'cvs up -j' but instead they'd initiate things from the merge

This creates a (small) problem for CVSNT where it doesn't for CVS.
CVSNT creates mergepoints (to track when a merge has occurred) when you
do an automatic merge 'cvs up -j', however if your merge is initiated by
an external tool like WinMerge or TortoiseCVS calling WinMerge in
side-by-side mode then the merge isn't tracked. At the moment it simply
means the information about the merge is lost.

Feasibility of this was demonstrated in the second half of September,
2001 but was largely ignored.

Can't remember it - do you have a link to the thread?

The thread began on September 14, 2001, with the subject "giving up CVS". A patch was posted with the subject " Demo of extensible merge (was Re: giving up CVS)".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]