[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: line-ending conversion and keyword substitution

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2001-12-11 22:22:09 CET

On Tue, 2001-12-11 at 15:43, Branko Čibej wrote:
> >I assert that (1) and (2) should always be the same, to avoid
> >irrevocably destroying data, even though that means the repository has
> >to store some gratuitous diffs a lot of the time. However, (3) should
> >be different; we should do a keyword substitution on the file after we
> >commit it, since certain keyword tags will become different as a result
> >of the commit. (No compelling reason to do a newline substitution,
> >though.)
> >

> But that's inconsistent. Following this recipe would get keyword
> expansions committed into the repository, thereby making diffs and
> merges of files with expanded keywords the kind of PITA they are in CVS
> today.

I think you are (1) not being sufficiently imaginative, and (2) assuming
that because CVS is imperfect, we can necessarily improve on it by doing
fundamentally different things.

I assume what you want to do is de-substitute keywords before committing
them (so that the repository only stores $Id$, for example). This is a
bad idea because:

  1. It loses potentially valuble information when you bring in files
from an outside source. CVS always preserves this information, if you
know how to get at it (-ko).

  2. It's not the only way to solve the problem. We can prevent keyword
merge conflicts by keyword-substituting the old and new text base (using
the same keyword substitutions as we used on the working copy).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:52 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.