CVS and Oxygen

[bwinspur]

Hi, thanks for a great product - I'd be non-functional without it.

However, I am having problems in managing an evolving docbook file in combination
with CVS. I'm posting this here because I hope that XML experts have already
encountered the problem and may know of workarounds, or knowledge that I need to
acquire.

I have an office workstation, and a laptop, and I use CVS as the means of
synchronizing what I do on the road with what I do on the office system. Incidentally,
I use eclipse, but I dont think that relates to my problem, but being a relative newcome
to CVS undoubtedly is a big part of the problem.

Symptoms
------------ If I religiously follow the prototocol
1. Start with both the laptop and desktop copies of the docbook file identical
2. Change the laptop version using OxygenXML
3. Commit the laptop changes to CVS
4. Update the desktop version from CVS
5. Change the desktop version using OxygenXML
6. Commit the desktop changes to CVS
7. Update the laptop version from CVS.
8. go to step 2.
------------ I dont have any surprises - all changes get committed and nothing is lost.

However: if I trigger a need to synchronize one copy or the other with the
CVS repository, by using OxygenXML on both the laptop and the desktop
copies without committing changes to CVS, the problem appears.

It seems that using the 'pretty print' operation of OxygenXML
(which I think is close to essential when editing docbook files), introduces too
many changes to be handled meaningfully by the CVS/eclipse combination
when presenting the data for synchronization. (I dont know exactly where the
problem lies).

The result is that instead of a few small overlapping changes to be reconciled, there
are huge segments of the document identified as having overlapping changes,
and it is almost impossible to see what the significant changes are. The net result of
my inexperience and the identification of spurious differences is that I'm loosing work
when I make my synchronization choices.

In an ideal world, CVS/Eclipse would understand XML syntax, would normalize white
space in documents stored the respository, and would then perform the
same normalization on documents to be committed, before analysing them for
overlapping diffs, which would then reveal only meaningful content changes.
On checkout the normalized docs could be pretty printed for human consumption.

Are there workarounds for the incompatibility of CVS diff analysis and pretty print?
Do I understand the problem correctly?

Thanks, Bill.

[george]

Hi Bill,

The diff performed by Eclipse is a text diff and that coupled with a format and indent in the document may cause indeed a large number of changes.
In general if you use the same settings for formatting then you should not get many differences with format and indent. However, it is better to use the Source->Pretty print element action instead, this has the same effect as a format and indent action but it is applied on the current element only, thus the potential of changing other parts of the document than the ones you edited is reduced.
We plan to add three way diff and merge support in oXygen (that is comparing two versions and a common ancestor) and integrate that into Eclipse as the diff support for XML files - we made this integration of the diff support in Eclipse but we realized that what we have is a two way diff and what is needed there is a three way diff so we postponed that until we will have the three way diff ready. There are plans to provide SVN (and probably also CVS) support in oXygen standalone and that will require also the three way diff and merge to be ready.

Best Regards,
George

[bwinspur]

George,
thanks for your reply. At least I understand the problem.
Looking forward to your 3 way diff plugin,
Bill.