Open Stack

2011/4/23 Thomas Goirand <thomas at goirand.fr>:
> On 04/22/2011 08:17 PM, Soren Hansen wrote:
>>> I wasn't discussing rebasing and hiding trials and errors or even
>>> rebasing, but cherry-picking things in a branch that we see fits,
>>> and are ready for a merge.
>> It may not be completely obvious on the surface, but those are
>> essentially the same operation. Rebasing is besically cherry-picking
>> a whole bunch of patches and applying them somewhere else.
> In Git, when we do "git cherry-pick -x <sha-sum>" it takes a patch
> from a branch, and put it in another one. That is what I meant. I
> don't see how this can be called rebasing. Rebasing is taking patches,
> and putting them on top of a branch, right?

I don't see how you can *not* see the similarity. Both take patches from
one place out of their context and stick them somewhere else. I'm not
saying the commands are synonymous or even share the same syntax, but
what they do is essentially the same. One acts on a single commit, one
acts on many. One pulls stuff from another branch into yours, the other
takes patches from your branch and puts them somewhere else (and then
makes that somewhere else your current branch).

>> You seem to have missed my final paragraph:
>>>> I completely agree that bzr should have better mechanics for sharing
>>>> working trees between different branches (the loom plugin does some of
>>>> this, if you're interested). Apart for when I'm working on the Linux
>>>> kernel, I've never really felt the need for it, but I understand that
>>>> many people do.
> I didn't miss it.

Perhaps you didn't miss it, but you don't seem to actually read it. :)
I'm *agreeing* that bzr needs to do this better.

> My point is that bzr is extensively using branching, so I think that
> doing a benchmark of any other thing isn't relevant.

Well, that's just silly. On a *really* busy day, I might create 5, 6 or
perhaps even 10 branches, but I make perhaps 50-70 commits. Why would
the cost of creating branches be so much more interesting that you think
the time to do anything else *at all* doesn't matter?

Just to throw some actual data in here, "bzr branch trunk newbranch"
costs me 1.5 seconds at the moment (where trunk is nova's trunk). With
10 branches a day, that's 15 seconds. Scattered across an entire day.

> I don't really care if a commit takes 15.8 or 16.3 seconds... Even
> comparing the branching of Git and the one of bzr isn't helping,
> because with Git, you'd do one branch once and for all, and work on
> it, then ask someone to merge it or cherry-pick few patches. While
> with the workflow we are using with bzr, we'd be doing branching for
> each single patch we need to give for review. So, we are actually
> using quite a lot an expensive operation.

That's exactly what I'm saying: bzr should do a better job at this (and
from what I can tell from, this work is being done as we speak).

> Also, the linux kernel shouldn't be the only example,

Oh, come on. First you say that providing data is useless, and now I'm
not providing enough data? I had to choose *something*.  Had I chosen a
smaller project, someone will inevitable have accused me of chosing it
because I was attempting to mask bzr's poorer performance.  Now I chose
the biggest repository I could think of, and the poster child for git.

> there are other projects that are big (firefox, openoffice, etc) and
> these wouldn't be manageable with bzr branching system.

I suppose you have some sort of data or similar to back these statememts
up? There are still *big* projects that still use subversion or even CVS
(e.g. OpenBSD) and manage to stay productive.

If people don't spend all their time arguing about tools, they can
actually get a lot of work done.

>> Of course I can't. I'm objecting to the fact that certain conventions
>> among users of certain tools encourage moving patches (not code, but
>> patches to code. Very different things.)
> Call me stupid, but ... can you please explain what's in the brackets?

A file full of code is different from a patch to a file full of code.
Simple as that. For example, an actual code file can be compiled. It's a
useful collection of bytes in its own right. A patch is only useful if
you have somewhere to apply it. If you take a patch that was made for
one file and apply it to another (say, if you take a patch for the linux
kernel and apply it to nova), no-one in their right mind would even
consider complaining to the author of the patch, and if they did, I'm
quite sure said author wouldn't give them the time of day. However, if
someone grabbed an entire file from somewhere, wanting to use it in
another project and had trouble getting it to work, at least that's a
semi-reasonable thing to do, and if the author of the file is so
inclined, they might actually extend a helping hand (rather than just a
single, particular finger).

> I really don't get it when you are saying "git is a patch management
> system and not a VCS",

I didn't. I said (paraphrasing slightly) "if you do so and so, you're
reducing your version control system to a patch management system." git
is, as far as I know, perfectly capable of maintaining history. It just
takes an annoyingly small amount of effort to convince it to *not*
maintain proper history of changes.

> or when you say "not code, but patches to code".  Why is bzr
> different?

I also never said that it was. I'm saying, in general, if you're
instructing your version control system to discard history, you're
turning it into a patch management system. It's not specific to git per
se, it's just that it seems to be a very common thing to do among git
users.

> In what way, new code stored in a patch isn't new code?

Applying a patch produces code. The patch itself isn't code. I
elaborated on the differences further up.
>
>> The problem is that the tools leave *no* way to tell if the change
>> has been cherry-picked and taken out of its natural context or if
>> it's in the exact place where I wrote it and tested it. It's the
>> revision control systems' responsibility to make this obvious, and
>> once you accept the concept of rebasing, you're instructing your
>> revision control system to lie.
> No. You might know it, I don't know. But with "git cherry-pick -x", it
> does leave clues in the log:

Of course it's possible to enumerate or annotate your patches any way
you like. Just like bzr makes it perfectly possible to do cherry-picking
(it's not a magic procedure.. It's about taking a patch from somewhere
and applying it somewhere else), it's just not an encouraged operation
because it discards history.

> Anyway, I guess that all the above (eg: branches vs cherry-pick of
> patches) is mostly a question of tastes. We can debate during hours,
> and still not agree. But it seemed to me that there's a majority of
> people in Openstack that are used to git and like the workflow I
> described. I'd be happy if others would express themselves about it,
> so that we can have a vague idea of what people think.

Democracy isn't always the best way to make decisions. First of
all, there's no way to bootstrap a project if you have to settle every
single religious debate before you can start writing code.  We made some
choices so that we could hit the ground running. If everyone had to
agree to any particular tool, we'd still be arguing over them. Second of
all, if everything was decided based on a vote, we'd be replacing half
our tool chain every other week, when the weight shifted in favour of
something else.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/