we need distributed control system
Par benoit12 le jeudi, juin 21 2007, 09:39 - Lien permanent
I have a commit access to GNOME svn, so i'm able to do whatever i want with my code, and then commit it. My main free software contribution has been GNOME for a long time.
I've recently started to hack on awffull (log analyser, it's a webalizer fork, but webalizer is dead). I keep submitting patches on the mailing lists, i'm mainly interested in memory usage, which is a real issue with huge logs, and even more on 32bits (allocating more than 2GiB is risky). One of my patch provides a 7% memory usage improvement by using flexible arrays : this saves millions of malloc calls so heap admin / malloc overhead is much lower.
But, even if Steve (upstream) and the mailing list people are great and very responsive, my patches have not been merged yet. I totally understand why they are not already merged, but i have no way to provide my branch to other awffull fans. So i started stacking everything in a local git repository. But now I need again and again to resplit the patches because upstream just can't merge my changes. I now realize how much we need distributed control system (git, monotone, etc). Without it, patches get lost on mailing lists, they get obsolete, they don't apply anymore ... a big waste of work.
With a distributed control system, upstream is able to pull from contributors, merge or cherrypick.
I'm frustrated about awffull, i now better understand how people could be frustrated about GNOME.
I am sorry for everyone (hackers, packagers, etc) who work hard on free software but are unable to (easily) get their job upstream because of the stupid VCS we are still using.
Commentaires
If you were a contributor to my project, I'd want to see patches, not a URL of some fork of my project, even if the VCS made it relatively easy to merge.
And if it was my project, I'd rather not see you suggesting that people use a fork of it.
sudo apt-get install git-svn
Wholeheartedly agreed. I, as a long-term maintainer of GNOME on NetBSD (not very active now, though), would really welcome a trivial way to maintain my portability fixes before they get integrated (which sometimes never happens, but that's another frustrating story). A DVCS could certainly simplify this.
Murray: It's OK if you want to see patches instead of a URL... it's the *tool* who should automatically be able to generate those patches. But the *developer* should be able to manage them more easily, and that is basically what a DVCS offers.
Murray > forking and branching are obviously not the same. I'am talking about how hard it is to merge when your VCS sucks at it. If someone wants to work a new feature, would you be OK if he would throw you a 10Kline patch ? And that guy would certainly quit because maintaining a 10K line patch against upstream is very very hard. Now it would be awesome if he could often pull/merge from upstream to update his new branch. In the end, to get the feature from upstream, you'd just have to pull from his branch. Or you could cherry-pick.
Jeff > git-svn does the opposite. And merging inside git-svn just blows the full revision history. And if everyone has to setup git-svn on his side, let's move to git/mtn/hg/etc
jmmv > I'm glad that you read that post. I was really thinking about your job. I know NetBSD has a patchset for GNOME. It's hard for you to maintain. And it's hard for me to get your patch. With DVCS, we could happily pull/merge/cherrypick from each other.
Have you tried using stacked git? (stgit) It's like quilt for git, and allows you to work in a patch-centric way. Basically, your current 'state' in a stgit-managed branch is managed in a bunch of patches, which are then applied in series.
Any changes you make are applied to the top-most active patch in your 'stack' when you invoke 'stg refresh'. The revision history of each time you do a refresh is there too, and 'qgit' (the best git GUI I've seen) understands the patches and their intermediary state.
The result is that you are always breaking things up into patches as you would submit them in a single unified workspace. The other option I could think of (but don't have a lot of experience with) is having one branch or workspace per patch you would want to submit, merging things across between them as desired.
The one downside to stgit in my mind is that when you push/pop patches onto the active stack (or just re-order them), timestamps of affected files may change even if their contents do not, which will confuse most build systems...
stgit looks fine, but svn + git-svn + stgit is too much.
Let's just switch to git. Moreover, managing patch is only good if you don't care about the revision log. A patch is the merge of all your work. On the other hand, when you merge, you get everything.
The problem is the upstream VCS and everyone seems to think that it's going to be solved by stacking again and again on the contributor side. This is just wrong. Managing patches feels quite stupid when you're used to use branch and do cherrypicking. cherrypicking makes patches useless i think.
> If someone wants to work a new feature, would you be
> OK if he would throw you a 10Kline patch
That doesn't happen very often. No VCS can make it easy to do big branches. Big branches are fundamentally difficult to merge.
When you do need to branch, I'm currently fairly happy with how svn does it. People have used bzr to branch from my svn, though I guess that doesn't make it so easy to merge back.
Most work is just small patches. I am very afraid of making life difficult for all those people, doing normal work, just because one or two people would like something that has a special feature.
It's a myth that DVCS are harder to use. A DVCS is not a toy for angry kids like me. I'm not having that discussion, sorry that you don't understand all the opportunities brought by DVCS. I think SVN sucks.
Murray: Sure the VCS cannot simplify the creation of big branches. But by using a DVCS it is extremely easy *for other people* to keep their personal branch in sync with the main one. It's not your job (as the maintainer) to do the syncing; it's the developers one. And with a DVCS it is much, much easier for them. Plus if you want (again, as the maintainer), you can merge the foreign branch (after a review, be it based on patches or whatever) and keep the *development history* for that foreign branch.
Let me suggest this talk about Git, given by Linus at Google: http://www.youtube.com/watch?v=4Xpn...
You have to be working "on the other side" (i.e. without access to the main project's repository) to really value the advantages of a DVCS.
I've never used git so I can't compare but bazaar (http://bazaar-vcs.org/) is great (it also have a svn plugin) - I prefere it over svn and cvs.
SVN is completely reasonable for a centralised mainline branch (and a project like GNOME does need a clear central mainline). With tools like git-svn and bzr-svn, it's very easy to branch into DVCS land and commit back to SVN. So, don't cry about GNOME's use of SVN -- use the tools that exist out there to make it work better for you!
Andrew > Thanks, stg is a very smart tool.
Jeff: It may be completely reasonable for *you* because you *already* have access to the repository. But those who don't (such as me) can really take advantage of a DVCS. You have to be on this side to understand the problems that arise; otherwise it's hard to explain. DVCS break the traditional "gain commit access" methodology, and all the elitism behind it. But anyway, and as Benoit already said, this is not the place to discuss whether DVCS are better or not.
You might want to use bazaar!
By installing the subversion bzr plugin, you can:
bzr clone http://path/to/svn
then when you want to merge, call
bzr pull
and to publish your changes
bzr push sftp://path/to/public/html
No James, this isn't enough. I'm already doing it with git, and it just doesn't work. With this kind of work, you end up pushing again and again ... and upstream just can't merge.