[Top][All Lists]

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

[Gnu-arch-users] Re: CVS gateway using cscvs -- tags and branches?

From: Miles Bader
Subject: [Gnu-arch-users] Re: CVS gateway using cscvs -- tags and branches?
Date: Tue, 24 Aug 2004 14:52:34 +0900

Martin Langhoff <address@hidden> writes:
>> > The practice, as I see it, is to refer to patchsets
>> > (repo/project--branch--version--patchset-NN) as a lightweight means
>> > of refering to a particular point in the project history.
>> Yes; is this not sufficient?
> Well, it probably is for a project run under Arch. Using CVS, I _have_
> found myself downgrading a file here and there (files that belonged to
> larger changesets) because they broke something, and then tagging for
> release/branch the 'known good' set of versions.
> You can't do this with Arch, and it may be a good thing. I don't know.
> In the scenario I've described, the proper thing should be to commit a
> changeset backing out some changes.

I don't know how cscvs operates, but the system I use operates purely
off of `cvs update', so if you're tracking a tag and it gets
"downgraded", it will _look_ to the gateway like a change backing out
the bug, and get committed to the arch branch as such.

>> In any case, you have to keep in mind that arch and CVS are really very
>> different, and you're simply not going to get a perfect gateway.
> Hmmm. I am aiming for a limited, but usable, gateway. Basic branches
> and tags would be nice to get going... ;)

Hmmm, I have my emacs CVS<->arch gateway (using an even more simplistic
program than cscvs) and haven't bothered to do anything for automatic
branch detection or trying to track tags.  I haven't missed them.

As far as I can tell, developers don't tend to do fancy things with CVS
because CVS is very easy to screw up.  Tags/branches in particular tend
to be either short-lived, temporary, per-developer magic things, or
long-lived; there's really no reason to track the former sort in arch,
and the latter I just manually enumerate (but I suppose tags with a
certain well-defined form could be easily automated anyway).


reply via email to

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