Re: VCS comparison table
- From
Martin Langhoff <martin.langhoff@gmail.com>
- Date
- Oct 24, 2006, 10:11 UTC
- Message-ID
- <46a038f90610240311n29d0561ek7dc52dc3d34c2f76@mail.gmail.com>
- In-Reply-To
- <845b6e870610240052l70ad72f4ma30065f151828dfd@mail.gmail.com>
On 10/24/06, Erik Bågfors <zindar@gmail.com> wrote:
> It's Erik :)
Sorry Erik!
> Let's make one thing clear. Revnos are NOT stored with the revision, > they are not "names" of the revision. They are basically just > shortcuts to specific revisions, that only makes sence in the context > of a branch.
My bad. The revnos examples discussed looked quite Arch-like. As Arch took them seriously, I thought bzr did too.
Probably quite a few people here thought as much, and got hot under the t-shirt about it ;-)
Now, the thing about they shorthand is that we have quite a few means of using shorthand in GIT that don't rely on revnos. We have the whole ^branchname stuff. And when you are looking at gitk it's pretty obvious which are your recent "local" commits.
...
> 2. treating "leftmost" parrent special is bad/good
Show 8 quoted lines
> 2. This is something I do care about. For me, this is the only > logical way of doing it. It might be because I am used to it now, but > when I started to look at bzr/hg/git/darcs/etc, I just got a so much > more clear view of the history when running a standard log command, > that it was one of the first things that attracted me to bzr. This is > just a user talking. > There might be technical reasons why it's better to not do it, but for > me it works the way I expect, therefore I'm happy
Can you give us a quick example of why you got such a clearer picture?
> 3. plugins are useless/useful
Hmmmm. It's more of a unix/C/pipes tradition vs dynamically typed & compiled scripting language tradition.
> 4. And now, storing branch information should be done manually (if > wanted) and not automatically.
> 4. No comment.
Probably not. But if someone is using branchnames to identify "lines of work" and hoping that metadata will remain attached there, it's probably a bad long-term approach.
But following what you said earlier about that info being transient and "local", then I was 200% wrong, and thinking of Arch/Bazaar usage patterns.
cheers,
martin