Jan Hudec пишет:
...
Reading this thread I came to think, that the revnos should be assigned
to _all_ revisions _available_, in order of when they entered the
repository (there are some possible variations I will mention below)
...
- They would be the same as subversion and svk, and IIRC mercurial as
well, use, so:
- They would already be familiar to users comming from those systems.
- They are known to be useful that way. In fact for svk it's the only
way to refer to revisions and seem to work satisfactorily (though
note that svk is not really suitable to ad-hoc topologies).
I think that SVN model of revision numbers is wrong. And apply it to bzr
break many UI habits. Per example, when ones use svn and their repo has
many branches you never could say what revisions belongs to mainline. So
things like
bzr diff -rM..N
(where M and N absolute revisions numbers, and N = M+1(+2) etc.)
will more complicated, because in this case you first need to run log
command, remember actual numbers of those revisions.
And I each time frustrating to see that after mainline svn revision 1000
might be mainline revision 1020. It's very-very-very confusing. May be
only for me.
There is 2 things why I don't want to switch to svn (if I can do my own
choice): their strange tags implementation (their tags is the same as
branches, so what difference?) and their revisions numbers.
I also think that dotted revisions is not answer in this case, but it
looks very logical and nice.
I think bzr need to have a switch, a flag, probably in .bazaar.conf to
show revno to user or revid. And user can easily select what model is
more appropriate for him:
* decentralized (with revno)
* or distrubuted (with revid i.e. UUID)
Comments?
-1 to make revno as in svn.
--
Alexander
-
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