Home » Newcomers » Newcomers » XML and CVS in Eclipse
| XML and CVS in Eclipse [message #129754] |
Sat, 14 January 2006 14:52  |
Eclipse User |
|
|
|
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 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. Being a relative newcomer to CVS undoubtedly is a big part of
the problem.
Symptoms
------------ If I religiously follow the protocol
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.
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 in the repository, and would
then perform the same normalization on documents to be committed, before
analyzing them for overlapping diffs, which would 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?
Does formatting java code produce the same kinds of spurious overlaps?
Thanks, Bill.
|
|
|
| Re: XML and CVS in Eclipse [message #130066 is a reply to message #129754] |
Tue, 17 January 2006 01:06  |
| Eclipse User |
|
|
|
Unfortunately CVS is not aware of the particular content type of files
commited to it. The only distinction it can make is whether a file is a text
file or a binary file. That being said, there is no way for eclipse to
special-handle files like xml. The only solution would be to have some other
tool or plugin that you would use to format and "unformat" files after and
before CVS operations.
In either case, this seems to be more of an issue with OxygenXML than
Eclipse, and you should enquire there (www.oxygenxml.com) for details about
the functionality of that product (as it is a 3rd party plugin). Perhaps you
do not have exactly the same formatting settings on your computers, which
causes the problems.
And yes, if different people using the same CVS keep reformatting java code
using different rules, then it would also be really difficult to see actual
differences.
Good luck
"Bill Winspur" <bwinspur@wynnon.com> wrote in message
news:dqbkqe$mol$1@utils.eclipse.org...
> 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 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. Being a relative newcomer to CVS undoubtedly is a big part of
> the problem.
>
> Symptoms
> ------------ If I religiously follow the protocol
> 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.
>
> 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 in the repository, and would
> then perform the same normalization on documents to be committed, before
> analyzing them for overlapping diffs, which would 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?
> Does formatting java code produce the same kinds of spurious overlaps?
>
> Thanks, Bill.
|
|
|
| Re: XML and CVS in Eclipse [message #130373 is a reply to message #130066] |
Wed, 18 January 2006 13:52 |
| Eclipse User |
|
|
|
Marcin Dobosz wrote:
> Unfortunately CVS is not aware of the particular content type of files
> commited to it. The only distinction it can make is whether a file is a text
> file or a binary file. That being said, there is no way for eclipse to
> special-handle files like xml. The only solution would be to have some other
> tool or plugin that you would use to format and "unformat" files after and
> before CVS operations.
> In either case, this seems to be more of an issue with OxygenXML than
> Eclipse, and you should enquire there (www.oxygenxml.com) for details about
> the functionality of that product (as it is a 3rd party plugin). Perhaps you
> do not have exactly the same formatting settings on your computers, which
> causes the problems.
> And yes, if different people using the same CVS keep reformatting java code
> using different rules, then it would also be really difficult to see actual
> differences.
> Good luck
>
> "Bill Winspur" <bwinspur@wynnon.com> wrote in message
> news:dqbkqe$mol$1@utils.eclipse.org...
>
>>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 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. Being a relative newcomer to CVS undoubtedly is a big part of
>>the problem.
>>
>>Symptoms
>>------------ If I religiously follow the protocol
>>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.
>>
>>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 in the repository, and would
>>then perform the same normalization on documents to be committed, before
>>analyzing them for overlapping diffs, which would 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?
>>Does formatting java code produce the same kinds of spurious overlaps?
>>
>>Thanks, Bill.
>
>
>
Thanks Marcin,
at least I understand the problem,
Bill.
|
|
| | |
| Re: XML and CVS in Eclipse [message #133636 is a reply to message #132385] |
Tue, 31 January 2006 16:13 |
| Eclipse User |
|
|
|
Bill Winspur wrote:
> Patrick J McNerthney wrote:
>
>> Bill,
>>
>> I get this same effect with Subversion when the I edit a file on my
>> Linux workstation that was originally committed using a Windows
>> workstation. The differing end of line combinations prevent any
>> meaningful merging to occur.
>>
>> Subversion does have a way to deal with this, there is a property that
>> can be set on a file that informs Subversion to use the native
>> operating system's end of line characters for that file. I am not
>> know if CVS has something similar.
>>
>> Anyways, check if it is an end of line change that is preventing your
>> merges.
>>
>> Good luck,
>> Pat McNerthney
>> ClearPoint Metrics, Inc.
>
>
> End of line does not seem to be a problem for me, both clients are
> XP pro. However, there may be small differences in the font rendering on
> my two systems that precipitate line breaks at different points by the
> reformat operation on each machine. That's just a theory to explain the
> differences I see after reformatting the same file on each system;
> I have no proof.
>
> Bill.
>
Ed Merks, in the foundation newsgroup, pointed out the ignore-whitespace
preference in Preferences>General>Compare/Patch
This will probably do what I want, thanks to all,
Bill.
|
|
|
Goto Forum:
Current Time: Sat Jun 07 11:33:15 EDT 2025
Powered by FUDForum. Page generated in 0.07907 seconds |
Home