Re: parsecvs and unnamed branches
- From
Jon Smirl <jonsmirl@gmail.com>
- Date
- Jun 16, 2006, 22:39 UTC
- Message-ID
- <9e4733910606161539t2485e3b3xa9f2852a4d2fc18f@mail.gmail.com>
- In-Reply-To
- <1150496362.6983.34.camel@neko.keithp.com>
On 6/16/06, Keith Packard <keithp@keithp.com> wrote:
Show 19 quoted lines
> On Fri, 2006-06-16 at 17:44 -0400, Jon Smirl wrote: > > I'm getting thousands of messages about unnamed branches and even > > 'unnamed branch from master-UNNAMED-BRANCH'. > > > > How do you get unnamed branches into CVS, are these check-in errors or > > are people actually working on unnamed branches? Or is parsecvs not > > finding all of the branch info? > > branch names rely on a special 'branch tag' in the "symbols" section of > the CVS file, but actual branches are flagged directly in the revision > list. I don't know how it happens, but ,v files often end up with > branches in the revision tree which haven't an associated tag. Go > figure. > > For example, in the top level mozilla/Makefile.in,v file, you'll see a > branch from version 1.36 with an initial commit 1.36.2.1. Using the > wacky CVS branch revision numbering scheme, there should be an > associated tag for version 1.36.0.2 (yes, the last two digits are > flipped). But, none is present in the file.
There is a branch label for SeaMonkey_M8_BRANCH:1.36.0.4 that does seems to correspond to anything. Could that be the missing tag?
Show 29 quoted lines
> > The reverse situation also occurs, with tags for branches that have no > revisions in the file. This case makes sense -- until you make a change > in a file along a branch, there will be no other record in the file of > where the branch came from. > > I'd love to figure out a better mechanism for merging these nameless > branches into the resulting repository, but I don't know how to > correlate unnamed branches in one file with unnamed branches in other > files. > > The current scheme of making up a fixed name and hoping that there > aren't multiple unmamed branches from the same root is probably fraught > with peril. > > -- > keith.packard@intel.com > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQBEky5qQp8BWwlsTdMRAvI1AJ4nXKyzeupTDarXI+yM0zvuHaCoTQCdEBYC > Kl7lEHIJgi5Tk24quc9FZyM= > =FA7H > -----END PGP SIGNATURE----- > > >
-- Jon Smirl jonsmirl@gmail.com