Harvard Business School of Echec - Tag - awffull - Commentaires

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Mon, 25 Jun 2007 11:32:36 +0200

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.

we need distributed control system - James

James — Sun, 24 Jun 2007 13:38:34 +0200

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

we need distributed control system - jmmv

jmmv — Thu, 21 Jun 2007 23:22:52 +0200

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.

we need distributed control system - Benoît Dejean

Benoît Dejean — Thu, 21 Jun 2007 23:18:23 +0200

Andrew > Thanks, stg is a very smart tool.

we need distributed control system - Jeff Waugh

Jeff Waugh — Thu, 21 Jun 2007 22:07:16 +0200

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!

we need distributed control system - Uzytkownik

Uzytkownik — Thu, 21 Jun 2007 16:36:52 +0200

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.

we need distributed control system - jmmv

jmmv — Thu, 21 Jun 2007 16:33:42 +0200

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.

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Thu, 21 Jun 2007 15:56:42 +0200

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.

we need distributed control system - Murray Cumming

Murray Cumming — Thu, 21 Jun 2007 15:35:41 +0200

> 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.

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Thu, 21 Jun 2007 14:32:53 +0200

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.

we need distributed control system - Andrew Sutherland

Andrew Sutherland — Thu, 21 Jun 2007 13:51:02 +0200

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...

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Thu, 21 Jun 2007 13:08:22 +0200

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.

we need distributed control system - jmmv

jmmv — Thu, 21 Jun 2007 12:32:31 +0200

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.

we need distributed control system - Jeff Schroeder

Jeff Schroeder — Thu, 21 Jun 2007 12:13:25 +0200

sudo apt-get install git-svn

we need distributed control system - Murray Cumming

Murray Cumming — Thu, 21 Jun 2007 12:07:26 +0200

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.