http://bazaar-ng.org/faq.html

[Petr Baudis]

Dear diary, on Fri, Apr 08, 2005 at 03:33:00PM CEST, I got a letter
where David Allouche <david at allouche.net> told me that...
> On Thu, 2005-04-07 at 18:40 +0200, Petr Baudis wrote:
> > Dear diary, on Thu, Apr 07, 2005 at 05:58:10PM CEST, I got a letter
> > where Daniel Gryniewicz <dang at fprintf.net> told me that...
> > > On Thu, 2005-04-07 at 17:39 +0200, Petr Baudis wrote:
> > > > 
> > > > Which is a shame, I think. I may be sick but I personally love the tags
> > > > and would like to retain a way to keep them (possibly more general way
> > > > to specify some rewriting rules when checking out files, dunno if it
> > > > could be useful for anything else though). Not that this is any major
> > > > thing, but still would be nice to have, I think. (Perhaps with a
> > > > per-tree keyword expansion policy possible.)
> > > 
> > > The problem, as I understand it, is that SCMs like bzr, baz, and tla
> > > don't have file versions, so there's no number to put into that ID
> > > string.  You could put the hash into it, but that's not very
> > > human-friendly...
> > 
> > The full equivalent in those SCMs is the last tree revision which
> > changed the file.
> 
> CVS keyword expansion is common flame fodder in the Arch community.
> 
> The bottom line, in that other community, is:
> 
>       * If keyword expansion is done on commit (i.e. the keyword is
>         stored expanded in the repository, no rewriting rules) you
>         introduce noise in the all changesets, and you get spurious
>         conflicts on inexact patching (merge or cherrypicking).
> 
>       * If keywords are rewritten (not stored in the repository), you no
>         longer have changeset noise, but that requires additional
>         complexity in commit and checkout, and that does not address the
>         spurious conflicts issue.
> 
>       * To address the spurious conflicts, you need to teach all merge
>         operators about keywords. And then they no longer merge what you
>         gave them, but what they think the files actually mean.
> 
>       * In a changeset-oriented VCS, keyword expansion does not have a
>         use case compelling enough to be worth the additional
>         complexity. 
> 
> The difference with CVS is that CVS merging abilities are very limited,
> so the keyword pain is low compared to the other merging pains.

I don't know what does this have to do with merging. Keywords are always
unexpanded inside the VCS, and are processed only when copying from/to
the user (that does not include merging - there's no reason to expand
keywords at that time). Just expand keywords when retrieving from the
archive to the checked out tree (sync, diff, update, ...), and collapse
when committing. And accept some -kk which will turn the keyword
expansion off, e.g. for preventing keywords to get into the way when
doing diffs. It adds some complexity, but only marginally it appears to
me.

> Please contradict me if I'm wrong, but I have the impression that the
> more knowledgeable people in the Arch community are strongly opposed to
> the use of CVS keywords in changeset-oriented VCSes.

Well, as long as bzr will be extensible enough that I could extend it
with keyword expansion through some hooks or something... :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.