The more I think about it the more I don’t want to pick a single DVCS for GNOME. It should be up to whoever is doing the work to use whatever tools they want. Unfortunately having each module choose its own hosting format has its own problems – do i need to check out gnome-super-cool from bzr.gnome.org or darcs.gnome.org? What if maintainer A likes cvs and maintainer B likes Git.
<snipped out the bit where i ramble about all the different options people have already suggested. me rambling FTYawn>
There is another approach. The Git protocol is quite easy. The Git pack container format is easy. The basic Git objects are easy. Who says i have to store Git packs in Git? As long as the client Git can grab packs and push packs it is happy. All other operations are local.
So lets take bzr-playground and run something that provides git:// and git+ssh:// access to the bazaar repositories. Push and pull. We’ll still have a central point from which we can view and checkout a GNOME module and the infra work can focus on a single platform. But the choice of tool i use to do my work is (partially at least) back down to me.
I am currently able to read and write the pack container format as well as speak a decent amount of the git-upload-pack and git-receive-pack protocols. It won’t be the first time i’ve serialized or deserialized git objects, so that won’t take very long. Then its just a case of storing things in Bazaar and maintaining a cache of sha1 to bazaar id. Sure, i’m trivializing here, but i am confident that this is doable.
I’m linking to the code I have so far (its an extension of bzr-git) as a gesture that this isnt total vaporware, but it’s not really anything you can try yet.
lp:~johncarr/bzr-git/git-serve
At this point im mainly interested in collecting +1’s and -1’s on the basic concept.
Without starting the this vcs vs that vcs flamewar, what is the real point? You take git and make it a lot slower this way. Why?
If you want git objects just use git. It seems simpler that way.
If someone checks out a Bazaar branch through this gateway, moves a file and pushes up the results, what does the resulting bazaar branch look like? How about when merges occur?
Unless I am missing something, this sounds like it could give the intersection of the features of the two version control systems rather than improving things.
@James Henstridge: Sure in the first case a rename *won’t* be recorded in Bazaar (eventually we can apply git heuristics as things are committed, but i won’t accept that as a valid answer). This is a price that a maintainer pays for using Git and one reason why eventually they might decide to (and have the option to) switch to using Bazaar.
I don’t see what the problem is when a merge occurs. When a merge occurs I trust the parents are stored and you have a way to get the full texts. So that merge can be represented in a meaningful manner in Git. Again, extra metadata that Bazaar might collect could be missed when pushing from Git to Bazaar but that is “the price of Git”.
When history is written it can’t be changed so there is no way for the bridge to corrupt the Bazaar branches in the Bazaar -> Git -> Bazaar process.
@Jeff Schroeder: What is the real point? Because unlike you I think people should have a choice? If speed is a problem we can easily speed the pulling and cloning case by keeping git-mirror. Given we are performing the same packing and unpacking operations git performs i don’t expect any problems, though.
I’d think it probably makes more sense to use git itself to host the backend and see if that can provide the bzr protocol, if only because it already provides a CVS protocol server and given lots of work on git-svn I wouldn’t be surprised if it were to provide SVN too.
Johannes Berg: Not really. The git format can’t hold all the Bazaar metadata. git-svn sucks and does not provide an svn server. bzr-svn does provide an svn server, though. Can’t say im interested in providing a CVS bridge…
Most importantly, Bazaar also provides a nice API for hacking this up. Git provides me with command line tools for hacking this up…
+1 for me.
As you outlined in your comments, the bazaar repositories contain more metadata than a git repository. Doing it the other way around (git backend providing an bzr protocol handler) just doesn’t make any sense.
This is an excellent feature. Having bzr support the protocols of other VCS tools makes it quite a lot easier for me to introduce bzr at my workplace. In particular, svn server support helps a lot at my company, but bzr server support certainly helps too.
+1.
I’m with you on the “devs should have the choice” issue. Why not just keep upstream svn and put the burden of integration on the people who want to use DVCS? Would obviously work best for bzr-affines.
>Why not just keep upstream svn and put the burden of
> integration on the people who want to use DVCS?
Hah? You mean people who want to stick to Centralized VCS that is brain-dead in many ways, should be taken seriously? You got to be kidding me.
Is this really worth the effort?
Why not use git (as it is _the_ LinuxVCS
) and provide bzr/hg/svn-like porcellain?
I would rather keep SVN than reduce choice (that wasn’t an option on the survey, dammit). The choices post migration haven’t really been explored too much. But I think using Bazaar as the common format provides a far far better bridge which can be done on the server side.
The thing is, sticking to SVN doesn’t mean sticking to CVCS approaches. The server is just a hard disk in the sky. The current problem is reallly just that git-svn is a really lousy IDE cable =), and the git:// protocol would make it like SATA or better.
-1 just use git
-1 just use git
I think that developers shouldn’t have a choice about it. Please follow what Keith Packard did with xorg; just switch to git and let people deal with the result. Bikeshedding sucks, just paint it git coloured (people won’t care all that much).
http://keithp.com/blog/Repository_Formats_Matter/
http://keithp.com/blog/Tyrannical_SCM_selection/
@menko: Bazaar is the GNU DVCS
Patches welcome for porcelain, but for me bzr git-serve is an easier approach.
@foo: Your -1 doesnt count, not a valid technical reason not to try.
@foo: (second post). Bikeshedding does suck. This post isnt about bikeshedding though. Its about ending the debate with a positive outcome for Bazaar and Git users.
The first point is about repository formats matter. His research in that area is out of date, and even git has gained a new format since then. I certainly wouldn’t call Bazaar broken, and wouldn’t be suggesting this if you couldnt put git data in and get same git data out.
The second link is about just doing it. The only people who have gone anyway to just doing it have been using Bazaar. Remember, git-mirror was only born because of someone rooting for Bazaar trying to do the right thing for the community (its not about me, its about us).
Keiths attitude is that sheep are bad. Everyone wanted to switch to SVN, but he thought GIT was better. A lot of the arguments for switching to Git over SVN don’t apply in the Git vs Bazaar case, and servicing different clients from a single repository is a lot easier.
When you have your local Git repository you won’t notice any “slowdown” from Bazaar, you want have any extra spurious crap like you see with the SVN interop stuff.
So really, what problems do you see in allowing 2 different clients? Perhaps we should make http://www.gnome.org only work with Epiphany?
Here’s why we should deprive our developers of choice:
1) It’s not newbie-friendy. The introductory page to hacking on GNOME gives the pros and cons of two different systems, and asks the new developer to pick one. The tutorial you are trying to follow shows commands for a different VCS. The person helping you on IRC on day 1 tells you to use one thing, and the person helping you on IRC the second day doesn’t understand that VCS. We have enough diversity and complexity in GNOME development without adding it here.
2) It’s not tools friendly. We should be continually working on server-side and client-side tools to make GNOME development easier.
3) It’s hard for me to believe there wouldn’t be some residual brokeness and weirdness from the mirroring. That type of small weirdness is easy to deal with *if you are a VCS expert*.
@Owen Taylor: Thanks for the comment, and I partially agree with your thinking. I see this as more of an opportunity to offer choice to those that want a choice, not about forcing choice on people who don’t know what choice to make.
In my view we’d still have a primary VCS. As this isnt mirroring, its one format with multiple server protocols, the server tools would be written against that one VCS. So its certainly not unfriendly to serve side tools. And jhbuild and anjuta and friends most likely cope with bzr and git at this point. I know jhbuild does, twas hit with my hammer.
Any documentation would favor the primary VCS, rather than confusing a user with choice.
There is still a central place to look – code.gnome.org, work.gnome.org, etc.
I cannot answer 3. Having dealt with git internals a lot i’m confident, but really i’d rather write it and have people see.
Calling Bazaar *the* GNU DVCS is just plain incorrect. Why promote a myth like that to make a (even a silly) point?
@Neo: “In early 2008, Bazaar became GNU Bazaar when release 1.2 was accepted as part of the GNU project.”. AFAIK, Git isn’t GNU Git, Hg isn’t GNU Hg. And AFAIK Bazaar is the only DVCS in the GNU project. So it is the GNU DVCS. What over DVCS has become part of the GNU project?
Thats not to say its the only tool used by GNU projects. IIRC, they actually have choice…
As a translator I commit to many, many, many modules in GNOME. it’s OK by me to allow developers and maintainers to choose a SCM, provided that I can use one (and only one) for all modules.
“And AFAIK Bazaar is the only DVCS in the GNU project. So it is the GNU DVCS. What over DVCS has become part of the GNU project?”
Are you just being silly or did you just forget
http://www.gnu.org/software/gnu-arch/
I could give you more details but then you can search as well
“Thats not to say its the only tool used by GNU projects. IIRC, they actually have choice…”
Canonical is trying it’s best to try to gain political mileage by making it a GNU project but without actually assigning copyright to FSF. Why bother about this in a technical debate?
@Neo: I thought Arch was dead, but fine. To be honest I never looked into it because it was a silly little throw away comment because the ” _the_ Linux DVCS” comment annoyed me. Not that I run GNOME on FreeBSD or anything.
I don’t know why you then chose to attack Canonical. I know a lot of people don’t like Canonical, i’m going to assume thats not involved here. Let me reiterate. I said GNU hackers can use Bazaar if they want, but they are not limited to this. They may choose to use Git. Or Mercurial. Or Svn. Or CVS. Or, as you correctly pointed out… arch. That has nothing to do with copyright assignment. So don’t bring it in to a technical debate.
The point is: GNU hackers have choice. We have limited choice and are currently voting to limit that choice even further.
Most people entering into this god damn bikeshedding are quite happy to get what they want and sod everyone else. No one else is thinking about how we can give devs what they want.
I have nothing more to say on the stupid GNU thing – this is about giving choice, not being a dictator.
[...] one, but bring to the people the way to use whatever they want or need for each project. I think John is right about that… why to choose for the people? Let’s people decide by [...]
Arch is not dead.
“I don’t know why you then chose to attack Canonical”
I don’t know why you are so defensive. It wasn’t a attack. Just pointing out a common source of confusion from people who think, if it is a GNU project, it is developed by FSF so we should pick that.
If you don’t want to have the debate, you shouldn’t have made the mistake of calling Bzr the only GNU DVCS project.
“No one else is thinking about how we can give devs what they want.”
How the heck do you know what other people want? You basically can NEVER give everyone what they want anyway. You have to limit choices and make some decisions. That’s the whole point. You are trying to weasel out by thinking “oh, this guy was foo, that guy wants bar and somebody else wants something else. Let’s all give them everything” without even thinking about the trouble you will create for L10N people for example who will be forced to learn dozens of different systems because you thought you were being clever.
“I have nothing more to say on the stupid GNU thing – this is about giving choice, not being a dictator.”
How about if some GNOME apps were written in QT in the name of giving choice. Sometimes you have to make a decision. if that means, dictating things, do that. Pick just one god damn scm system and stick with it.
@John Carr: The original idea you propose is very cool, but overly complicated and trying to solve the wrong problem. Personally, I think we should have git AND bzr mirrors of the full gnome trees. That way, users using either can benefit from whatever suits them best.
bzr has changed their repo format what, 2 or 3 times now? Something insane like that. bzr kicks the crap out of git by having a full api that is easy to work with. git kicks the crap out of bzr when it comes to speed and managing very large repositories. git also seems (my opinion) to have much smaller repositories on disk than bzr.
Your idea would limit gnome to the common featureset of both dcvs implementations and strip out what makes them both shine. That is why I respectfully disagree. Just my 2 cents.
@Jeff Schroeder: We already have git AND bzr AND hg mirrors of the full GNOME trees. Are you saying we shouldn’t move from SVN? Commiting to the central server is the limiting factor here, and thats why this dicussion is happening. The mirrors alone are not enough.
The bzr repo format doesnt matter so much – svn also has changed its format and svn.gnome.org has been upgraded to use smaller more featureful formats. For our server side, the the size doesnt matter so much. We are going to save on space over SVN. (Note: This claim is based on an older version of SVN, my local SVN mirror of svn.gnome.org hasnt been upgraded to 1.5).
So let me just explain an important part of the idea again. Git doesnt care about how the data is stored on a remote server, so long as it can exchange pack files when pushing and pulling. Pretty much for full Git history to be preserved we just need to store committer, author, commit message, timestamp. list of parents, list of files and raw file “blobs”. Theres no complicated metadata to mangle from one format and back again. Its easier than syncing your mobile phone to linux. NO features of Git are harmed in the making of this walnut flavoured ice sculpture.
By putting this mapping on the server side we also need to make no attempt to represent Bazaar metadata in Git format. The git repositories will be “pristine”.
Thank you for your polite comment, its very refreshing. I’d be interested in replying to any other further (specific) concerns you have over this. You comment, “That way, users using either can benefit from whatever suits them best.”. This makes me think we both want the users to have choice, so i’m uncertain why you disagree (the only other options open to GNOME right now WILL lessen my choices).
“”"I’d be interested in replying to any other further (specific) concerns you have over this. “”"
Show us the code
@Jeff Schroeder: Eh. No more whiskey and Halo and replying to comments for me, then
John: Though I was one of the ones arguing against Keith at the time (late 2005 or early 2006), I think we made the right choice for more or less the right reasons. Eventually someone was just going to have to pick something. He did. At the time, git was not the clear-cut winner it is today (maybe this is just me being dumb, but it does seem like the obvious choice now, given the kernel, X.Org, freedesktop.org, GitHub, et al), but no-one was arguing for SVN.
The argument at the time was more along the lines of:
* git’s UI is dire
* git still lacks a few features, though has a very active development base
* bzr is unusably slow and the repository size is ludicrous, though it also has a very active development base and a well-documented UI
* git makes too many mistakes that remind you of tla[0]
* interesting projects in mercurial, darcs, codeville, rosegarden, etc; though they couldn’t really be taken seriously in themselves, it was something to watch as new systems could build upon existing implementations (e.g. bzr building on darcs and tla/baz as well as its own design from mbp’s work)
If we were having that argument today, it would look like:
* git is still the speed king
* git’s remaining UI mistakes (mainly forcing people to care about the index: -a as default kthx) are too small to really matter, well-documented, and will probably disappear soon; for a basic operational cheat sheet, bzr and git are today equally usable
* git still produces vastly smaller repositories than the competition, and bzr still don’t seem to have a coherent repository story (though this may have changed in the past few months) and guarantee of both forward- and backward-portable formats
* more projects seem to have adopted git than bzr, with bzr probably getting more initial interest but git really picking up and moving up the stack in 2008 (and hey, git -> ruby -> gospel, right?)
* no-one cares about anything other than git or bzr, and the rush of new VCSes has settled down
So it’d be a clear winner and we’d switch with no protest, although our development for the last two and a half years would’ve been crippled compared to what we’ve enjoyed since then.
[0]: Except that the designers aren’t idiots and thus the short-sighted crap (the implementation is the only sensible UI, users find revision control fundamentally interesting, porcelains will save us from our godawful UI) was eventually beaten out.
@daniels: Thanks for the comment. It’s nice to hear from Git users without passionate ranting. I’m not saying that Git isn’t a good choice. I’m not saying Bazaar isn’t a good choice. While I happen to prefer Bazaar, my preference certainly isn’t based on thinking Git is hard and giving up – i use both quite a bit. I’ve also had more 1-on-1 time with the Bazaar developers.
I look forward to when Git reaches “2.6″ status (hopefully with an LGPL library backend to it), but anyway..
The main point i’m saying is: If we can support Bzr and Git without crippling anyone like git-svn does, why don’t we. Then I don’t really care about which one is the one we tell people to use.
Why does it matter to the Git people if we don’t exclude the Bazaar people? You wouldn’t get away with only accepting patches from Vim users, would you? (I’m waiting for someone to flame that..)
People worried about the mapping should just wait for me to get to alpha, then we can see
People worried about the speed needn’t.
@daniels: “no-one cares about anything other than git or bzr, and the rush of new VCSes has settled down” is totally wrong. I wouldn’t call Mozilla, OpenDolaris, OpenJDK, Netbeans or Xen small residual projects that don’t mind in the FLOSS world, and they chose hg (mercurial) over git or bzr for good reasons.
@daniels:
I think bzr 1.9 with groupcompress on wins sizeably in the pack alogithm stakes and repo size. I can’t find some hard numbers to point to, but I gather lifeless has some stats.
Also, in terms of git being stable repo format, that really isn’t true. There have been a good few changes to both loose and packed objects (look for all the special casing). The real mother will be when SHA1 becomes vulnerable (and given usual hash function lifetimes, that’s surely relatively soon). Think about how git could actually cope with this. Its doable, but man, it’s going to be messy.
Also, git’s UI mistakes are still myriad and aren’t going away. Calling the index the index is still foul and will never change, git add as modifying the index is still stupid and will never change now, etc etc… and really, I’ve tried hacking on git’s UI, the code is so horrible and convoluted that its near impossible to fix things like the user-incomprehensible error messages that still come out.
“Also, git’s UI mistakes are still myriad and aren’t going away. Calling the index the index is still foul and will never change, git add as modifying the index is still stupid and will never change now, etc etc… and really, I’ve tried hacking on git’s UI, the code is so horrible and convoluted that its near impossible to fix things like the user-incomprehensible error messages that still come out.”
And if your task is formatting nice patches, rather than dumping it all in a version control system, the index is a great tool. I personally consider the index a fantastic feature (and I am sure lots of git users will agree). Not being able to do these kinds of in bzr is a horrible mistake to me.
So depending on what your point of view is, the other system is a mistake. Just don’t assume everybody thinks like that, unless you have the numbers to prove it.
@anon: I don’t know why i’m replying – you won’t know I have.
Actually, he doesnt say the index is a bad thing. Just that the UI for it is kind of sucky. But soon Git will have a new name for this, woo! Hopefully the index is still around so peoples scripts carry on working.
I personally use “git rebase -i” and “git add -p” more when trying to get a nice patch series. I often frowned that I couldnt do this in Bazaar, then found out I could. I like using bzr looms so that I can version the patches too, i believe this is similar to topgit but havent any experience with that.
You can use bzr’s shelf (stash) to emulate the index, and i expect a more natural way of doing this in future releases.
[...] have been discussing DVCSes a lot lately, and at least one seems to prefer bzr as the repository format and git as the protocol it speaks. If this sounds like madness to you, you’re not [...]