On Tue, 19 Sep 2006, Joel Dice wrote:
>
> I'd be happy to put together a patch that implements this, but first I'd like
> to get some feedback. If something like this has already been proposed,
> please point me to the discussion. Thanks.
I really don't think you can do it sanely.
The thing is, the reason subversion can do it is simply that SVN is
terminally broken.
Really. SVN is crap. It may be prettier crap than CVS, but it's literaly
no different from putting confectioners sugar on top of a cowpatty. It's
not really "fixing" anything. And the revision numbering is actually very
much part of the problem.
The thing is, you can limit yourself to a single repository, and once you
have branches, you _still_ cannot sanely number the commits with anything
like "r1.3.4.1".
Here's an example. Let's say that you start out with just a regular
"master" branch, and you number the commits "r1.1", "r1.2" and so on (of
course, that extra "1." at the beginning doesn't actually make any
_sense_, but let's keep it just to not confuse CVS/SVN users any more than
they are already confused).
Now, you've done five commits, and are at "r1.5", and everything looks
beautiful, and you're getting comfy, so you start and check out a branch
called "test". What do you call it?
The thing is, you need to call it "r1.5", because the _commit_ is still
exactly the same as the master one. Creation of a branch in git doesn't
actually create any new commits, it just creates a new pointer.
So far so fine. We can ignore that, and make the rules be:
- when creating a commit, we look at the branch name. If the branch name
is "master", we increment the second number, and drop all other
numbers.
- if the branch name is anything else, we look whether the current state
is the same any other branch, in which case we just add a ".1" at the
end relative to the branch (or a ".2" if a ".1" already exists and so
on). Otherwise we increment the last number.
that's not a wonderful set of rules, but it might work. So what happens is
that when we create the next commit (on the "test" branch), that commit
will be called "r1.5.1" (which is what you'd expect). Go along a bit, and
you get "r1.5.2" and "r1.5.3" too. Wonderful.
Now you decide to merge this back into "master". Which, btw, hasn't had
any actual development happen, so it's stil at 1.5. You check out "master"
and do a "git pull . test" (or "git pull . r1.5.3", which is obviously the
same thing), and what happens?
That's right, we now fast-forward master to that revision, since nothing
happened on master. Which means that your master branch is now comprised
of revisions "r1.1" .. "r1.5" "r1.5.1" .. "r1.5.3". That makes no sense at
all, but it works. The next commit would be called "r1.6".
In other words, the SVN numbering is just insane in a git repo, although
you can "make it work" in a limited sense (but the numbering would jump in
odd ways. The thing is, all the things that are true in a distributed
environment are true in a single repository too, so limiting yourself to
a single repo doesn't really make them go away.
Another thing you CAN do, is to just number them in time in a single repo.
Every time you do a commit, you can create a "r1.<n+1>" revision, and that
would work. It wouldn't look like the SVN numbers do, and it would only
work _within_ that repository, but it would work.
But it would mean that "r1.57" is _not_ necessarily the child of "r1.56".
It might be that "r1.56" was done on another branch, and is totally
unrelated to "r1.57" (other than they sharing some common ancestor far
back).
See? The SVN (and CVS) revision numbering really only makes sense because
it's fundamentally a non-distributed model.
Git is so _fundamentally_ distributed that even within one single
repository, each branch is totally independent ("distributed"). In
CVS/SVN, branches aren't independent of each other, and that's why they
show up in the revision numbering.
So you can really only number things as long as you never do any branches
at all, and just do a linear development. In that case, and in that case
only, does numbering work. Or you'd have to have a very "non-git" approach
to branches (the above silly rules _can_ be used - possibly with some
fixes - to give you essentially SVN-like revision numbers, if you _always_
generate a commit when you merge).
It doesn't seem to make a whole lot of sense, does it?
Btw, along the same issues, BK actually had RCS/CVS/SVN-like revision
numbers, but to solve the distributed problem (BK didn't have branches) BK
had a different approach.
So BK actually _did_ number things as "1.1" and "1.4.6" etc, and was
obviously distributed, and the revision numbers actually matched the shape
of the development history the same way CVS/SVN does. But if you do that,
what happens is that a merge will _change_ the numbers: you may have
started with two different branches that both were at "r1.2", but at the
end of it one of them got renamed to "r1.1.1", and the final result was
called "r1.3".
So if you allow malleable revision numbers, you can definitely do it. That
ends up being _really_ confusing. I know a number of people who otherwise
were smart really never understood why "r1.576" might not stay as "r1.576"
forever, but might suddenly become "1.401.3.55" when merged into another
repository.
Anyway, what I'm trying to say is that you're probably better off trying
to get used to the git numbering than trying to force the SVN model.
You're going to hit a few confusing issues if you really want to call
things "r1.x.y.z"
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html