On Tue, 11 Dec 2001 21:43:10 +0100
Branko �ibej <brane@xbc.nu> wrote:
...
> > 1. The bits of the file on disk, before the commit command is run
> > 2. The bits which are committed to the repository
> > 3. The bits of the file on disk, after the commit command is run
> >
> >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.
Well said.
We have to be very careful to avoid the keyword merge problems in CVS.
When you do a big merge almost all of the "conflicts" for a given set of
files are just text diffs in the RCS keyword expansions. It is really quite a bother.
Why can't we just assert that no keywords will ever be expanded in the
repository? Can't we store the keyword itself in the repo? Can't we just
expand the keywords on checkout or update?
cheers
Mo
---------------------------------------------------------------------
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