|
Actions:
|
2008-04-29 10:06 AEST by Arthur Barrett - Enahncement proposal for extensible -j merge for non-text file types (eg: gif,
xml). In particular merging XML 'settings' or 'configuration' files would be
done on a node-by-node basis (and conflicts also handled that way) rather than
on a purely textual basis.
This possibly would depend on "enh: check files conform to mime type/well
formed/obey schema" bug5243.
This was originally discussed on info-cvs (the nongnu cvs) newsgroup - 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)". The discussion was revised recently in a thread titled "How to treat
XML files checked into CVS" beginning on April 16, 2008.
This proposal is different to the xdiff plugins that CVSNT already has.
This proposal would be useless for UD6 XML files (MS: XML-DATA) since these are
better off merged on a text basis and in fact designed for that purpose (eg:
the nodes are always in the same order, and can contain 100Ks worth of CDATA).
This potentially highlights the danger of an XML specific -j merge. It would
probably be best if a file was identified as a specific type similar to how we
already handle 'text' and 'binary' (b or B) we'd need a 'xml' and a 'gif' type,
or more generally an 'external' type (ie: diff/merge) is handled by an external
diff routine.
One of the many problems with this is that 'text' and 'binary' (b or B) really
define the cvsdelta algorithm as well as the (client) merge behaviour, and we
would quite possibly want 'gif' deltas in the RCS files still stored as binary
B and xml still stored as text RCS deltas, but just alter the merge behaviour.
The second of many 'problems' is that many users use tools such as WinMerge to
do their merging than the 'cvs up -j' - in fact I find myself using it quite
often - particularly where I want to review the merge carefully anyway. A
fancy -j merge wouldn't help this at all.
Paul Sanders who originally discussed this on the newsgrou on April 16 2008
seemed happy enough to discuss it, and also was clear that it is still seen as
a requirement for him, in particular in the ability to eventually handle
complex formats such as MS-Word. Now that MS have finally released the
(word95/97) file formats this is at least technically feasible. You could even
merge photoshop (PS) files by inserting the merged image as new layers in the
original (if you got fancy with layer names you could possibly even determine
if an image had been previously merged - but better to use mergepoints I
think). Paul even suggested that Java is well-formed enough to warrent a
specific merge algorithm in particular "The insertion, deletion, or
modification of control structures and expressions without regard to cosmetic
formatting or the history of how such control structures and expressions came
into being".
This may very well be the sort of thing we are better off putting into EVSCM
simply because no matter how many features we add to CVSNT many people ignore
them and claim "oh it's just cvs for windows" and the real valule of the
features are lost - at least with EVSCM we are actively working on saying "it's
not CVS". The problem with making this an EVSCM feature is that there is a
higher conversion cost and it probably wont make the initial release, so people
who are looking for just this feature may dismiss EVSCM early on. The only way
to address this would be using the SVN technique: implement it poorly in
release 1 and then improve it (or more in SVN's case: claim it's in release 1
and add it five years later). |