[parisc-linux] CVS rumors

[Michael Ang]

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 
adding a
 > = 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 :-( :-(


Ugh.


 > = Where does the code for safe-cvsimport live?
 >
 > http://puffin.external.hp.com/cvs/build-tools/safe-cvsimport
 >
 > 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".

	- Mike.