[parisc-linux] CVS rumors
Thu, 12 Jul 2001 11:01:07 -0400
Paul Bame wrote:
> = Tags are cheap. Explicitly tagging at important moments is the way to
> = go. Relying on a date-based checkout is potentially less accurate, so
> = IMO this shouldn't be the common practice. There's no harm in
> = static tag, and you can always remove it or possibly fix it up if you
> = get it wrong.
> Tagging a linux source tree over the network is slow however.
True, but in the absence of a working date + branch checkout, it's a
reasonable interim solution (real solution is to fix cvs).
> More information on date+branch CVS checkouts: When there are multiple
> branches, a date-based checkout must also supply a branch, implicitly
> or explicitly, to disambiguate. RCS has this feature
> and it works fine (see the 'co' man page). I can't force CVS to do it
> though, on the trunk anyway, despite it's being built upon RCS :-(
> So the workaround for date-based checkout of our trunk is.... use RCS
> on a copy (can be 'cp -l') of our CVS repository :-( :-(
> = Where does the code for safe-cvsimport live?
> Beware -- it uses 'cvs admin -b' plus at the moment seems not to remove
> upstream-removed files correctly. I'm thinking of re-doing it to
> avoid using 'cvs import' altogether -- it is in need of a rewrite.
I don't know of any way to get rid of the vendor branch taint other than
using 'cvs admin -b' or (less preferably) rcs directly.
> = I haven't been following things enough to know what
> = the issues related to "the vestiges of upstream imports" are.
> At least one upstream import+merge was done directly to the trunk. So
> changes which came with that import are unresolvable by
> CVS during a merge and can require some sleuthing -- particularly
> any files which were added/deleted at that time.
Ouch. The import should have some distinct tag, and I guess using a
date tag is the best you'll get for trying to determine the state prior
to the merge (which, according to Murphy's Law, I predict overlapped
regular development). My best advice is "don't do that then".