Re: VCS comparison table
- From
Andreas Ericsson <ae@op5.se>
- Date
- Oct 17, 2006, 08:16 UTC
- Message-ID
- <45349162.90001@op5.se>
- In-Reply-To
- <45346290.6050300@utoronto.ca>
Aaron Bentley wrote:
Show 11 quoted lines
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jakub Narebski wrote: >> Well, <ref>~<n> means <n>-th _parent_ of a given ref, which for branches >> (which constantly change) is a moving target. > > Ah. Bazaar uses negative numbers to refer to <n>th parents, and > positive numbers to refer to the number of commits that have been made > since the branch was initialized. >
What do you do once a branch has been thrown away, or has had 20 other branches merged into it? Does the offset-number change for the revision then, or do you track branch-points explicitly?
Show 26 quoted lines
>> One cannot have universally valid revision numbers (even >> only per branch) in distributed development. Subversion can do that only >> because it is centralized SCM. Global numbering and distributed nature >> doesn't mix... hence contents based sha1 as commit identifiers. > > Sure. Our UI approach is that unique identifiers can usefully be > abstracted away with a combination of URL + number, in the vast majority > of cases. > >> But this doesn't matter much, because you can have really lightweight >> tags in git (especially now with packed refs support). So you can have >> the namespace you want. > > The nice thing about revision numbers is that they're implicit-- no one > needs to take any action to update them, and so you can always use them. > >> I wonder if any SCM other than git has easy way to "rebase" a branch, >> i.e. cut branch at branching point, and transplant it to the tip >> of other branch. For example you work on 'xx/topic' topic branch, >> and want to have changes in those branch but applied to current work, >> not to the version some time ago when you have started working on >> said feature. > > If I understand correctly, in Bazaar, you'd just merge the current work > into 'xx/topic'. >
merge != rebase though, although they are indeed similar. Let's take the example of a 'master' branch and topic branch topicA. If you rebase topicA onto 'master', development will appear to have been serial. If you instead merge them, it will either register as a real merge or, if the branch tip of 'master' is the branch start-point of topicA, it will result in a "fast-forward" where 'master' is just updated to the branch-tip of 'topicA'.
Show 24 quoted lines
>> What your comparison matrick lacks for example is if given SCM >> saves information about branching point and merges, so you can >> get where two branches diverged, and when one branch was merged into >> another. > > I'm not sure what you mean about divergence. For example, Bazaar > records the complete ancestry of each branch, and determining the point > of divergence is as simple as finding the last common ancestor. But are > you considering only the initial divergence? Or if the branches merge > and then diverge again, would you consider that the point of divergence? > > merge-point tracking is a prerequisite for Smart Merge, which does > appear on our matrix. > >> Plugins = API + detection ifrastructure + loading on demand. >> Git has API, has a kind of detection ifrastructure (for commands and >> merge strategies only), doesn't have loading on demand. You can >> easily provide new commands (thanks to git wrapper) and new merge >> strategies. > > I'm not sure what you mean by API, unless you mean the commandline. If > that's what you mean, surely all unix commands are extensible in that > regard. >
I'm fairly certain he's talking about the API in the sense it's being talked about in every other application. Extensive work has been made to libify a lot of the git code, which means that most git commands are made up of less than 400 lines of C code, where roughly 80% of the code is command-specific (i.e., argument parsing and presentation).
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231