Re: parsecvs and unnamed branches
- From
Jon Smirl <jonsmirl@gmail.com>
- Date
- Jun 16, 2006, 22:28 UTC
- Message-ID
- <9e4733910606161528n668a96afgefca16644f8038b6@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.
I was reading the CVS manual and it talks about magic branch number as being the ones with zero in them. Doesn't go into a lot of detail. Apparently they are autogenerated internally.
http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Branching_and_merging#Magic_branch_numbers
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