info-cvs
[Top][All Lists]
Advanced

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

Re: cvs merging - conflict


From: Kaz Kylheku
Subject: Re: cvs merging - conflict
Date: Thu, 17 Jun 2004 09:12:05 -0700 (PDT)

On Thu, 17 Jun 2004, Feldmann, Rick wrote:

> Date: Thu, 17 Jun 2004 11:53:55 -0400
> From: "Feldmann, Rick" <address@hidden>
> To: 'Kaz Kylheku' <address@hidden>
> Cc: "'address@hidden'" <address@hidden>
> Subject: RE: cvs merging - conflict
> 
> Kaz,
> 
> Thanks for the reply.  Nice explanation of the differences.  As for white
> space, I'm not asking for the machine to blindly throw white space away, I'm
> asking for the ability to tell the machine to throw away white space.  It
> doesn't even have to be the default, just an option.  

The problem with that is that the project now has users who are
deciding to use an option. So from the configuration manager's point of
view, he has a machine (system + programmers) that is doing silly
things. :)

The whitespace truly has to not matter, no matter where it occurs.

In your case, you are dealing with XML, in which whitespace does
matter. Not everywhere, of course, but in some contexts, like the
data itself:

<foo> </foo> is different from <foo></foo>

<foo key="value "> is different from <foo key="value">

There is no telling how such differences will affect some process that
uses that XML as input.

If there are merge conflicts due to different line terminators, that is
a different problem. CVS stores text files in a canonical format on the
server, and converts them to and from the client's text file
representation. So normally there are no problems.

Sometimes people things which cause this scheme to break.  For instance
they transfer files between systems that have a different text file
format without converting them, and then commit them into CVS. So you
end up with stray ^M characters when checking out these files.





reply via email to

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