git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Mansfield <centos@dm.cobite.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: David Mansfield <cvsps@dm.cobite.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFC] Make dot-counting ignore ".1" at the end
Date: Fri, 24 Mar 2006 09:40:48 -0500	[thread overview]
Message-ID: <442404F0.80609@dm.cobite.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603221746300.26286@g5.osdl.org>

Linus Torvalds wrote:
> I'm not 100% sure this is appropriate, but in general, I think "<rev>" and 
> "<rev>.1" should be considered the same thing, no? Which implies that 
> "1.1" and "1.1.1.1" are all the same thing, and collapse to just "1", ie a 
> zero dot-count. They are all the same version, after all, no?


Hmmm.  I'm not sure about this. Given x.y.z.q... the 'odd' nodes 
(starting from x = position 1) represent branches, not revisions, and 
don't refer to actual concrete objects (just tags if you will) in the 
cvs world.

So if <rev> is something like x.y then x.y.z would refer to the 'z' branch.

Furthermore, 'z' better be an even value 2 4 6 etc. because those are 
the only branch id's cvs will create.  The odd values are for 'imported 
source' branches.

The reason 1.1.1.1 exists is some lame-ass crap that CVS delivers to any 
developer who imports his/her initial source code.

It creates 1.1 as a placeholder, and I think in this special case it has 
the same contents.  It also creates a .1 'import branch' then puts the
imported revision onto that 'import' branch.

In a normal situation, you have rev = x.y

You branch, it 'registers' a branch x.y.z where z in {2,4,6...} (and 
uses a special 'magic branch' syntax x.y.0.z in the symbolic tags 
section).

Only when you commit your first change does it create x.y.z.1.

So we have:

x.y != x.y.z.1 for sure, in the general case.

Also x.y.z will never be x.y.1 for a user created branch because z must 
be even number (except for import branches), in any case x.y.z is never 
an actual file revision.  Now, it COULD be the fact there there needs to 
be special handling for x.y.z where z == 1 because that is an import 
branch and something devilish is happening there.

I honestly don't know...

David

  parent reply	other threads:[~2006-03-24 14:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-23  1:29 Fix branch ancestry calculation Linus Torvalds
2006-03-23  1:50 ` [RFC] Make dot-counting ignore ".1" at the end Linus Torvalds
2006-03-23  6:26   ` Keith Packard
2006-03-23  6:34     ` Linus Torvalds
2006-03-23  7:17       ` Keith Packard
2006-03-24 14:40   ` David Mansfield [this message]
2006-03-24 14:45 ` Fix branch ancestry calculation David Mansfield
2006-03-24 15:46   ` Linus Torvalds
2006-03-24 16:38     ` Keith Packard
2006-03-25  1:45       ` Chris Shoemaker
2006-03-25  7:54         ` Keith Packard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=442404F0.80609@dm.cobite.com \
    --to=centos@dm.cobite.com \
    --cc=cvsps@dm.cobite.com \
    --cc=git@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).