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

David Allouche david at allouche.net
Fri Apr 8 14:33:00 BST 2005


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.

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.

-- 
                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050408/b8736a47/attachment.pgp 


More information about the bazaar mailing list