Branches are Bad? (was: Re: What are the strengths of Mercurial for you?)
Douglas Philips
dgou at mac.com
Sun Jan 11 00:09:33 UTC 2009
On or about 2009 Jan 10, at 3:02 PM, John D. Mitchell indited:
> How often do multiple head problems come up in this forum?
Again, as far as I can tell, multiple head "problems" are due to CVCS
poisoning.
Having a separate repo/clone for each head seems to be a symptom of
the same issue.
But DVCSes don't care which way you do it.
Or perhaps it is the novelty of being able to have clones "that work
right" which makes using them seem so much better/right?
> But even more importantly, IMHO, is that your statement is precisely
> an example of my earlier point. You've internalized the "solution"
> and made it not bug you anymore because you've set up your workflow
> by fiat and convention (e.g., what about people who don't use
> NetBeans?). You can get all of the benefits of that using clones.
I don't argue that multiple-heads are better than clones, just that
they are not worse.
> Sounds like you don't have to ever deal with large artifacts and/or
> huge teams and/or external/untrusted/unlicensed-to participants. Be
> thankful. :-)
<Shrug>. Lots of big open source projects have converted to DVCSes and
they want to have decades of revision history, so I don't see that
even in other projects "huge teams" are a problem for DVCSes.
>>> * the dirty commit history?
>>
>> What does that mean?
>
> It means that you have a lot of commit history in your repo from all
> of those branches getting pulled into the mainline. Makes it messy
> and hard to do some things cleanly such as bisect (e.g. erroneous
> failures).
It seems that you might be conflating several things here...
If I have a 10-headed repo, I can choose to just release my ready-to-
release head(s) to the mainline (push or pull doesn't matter, either
one lets me cherry pick heads). Or I if I had 10 clones, I could do
the same. But then, since the other end can't tell the difference, I'm
free to choose whichever strategy works for my individual workflow.
But somehow I think that isn't what you mean, I'm just not sure what
you do mean...
bisect, however, is just broken.
bisects requirements/attitude seems to me to be left-over CVCSism that
equates commit and push/share.
Fortunately Mercurial gives me the freedom to say that my policy is
that I want to "see the work" and not just some fait-accompli shiny
turd from the forehead of Zeus changeset (i exaggerate for effect, but
only slightly).
If my policy decision 'breaks' bisect, then bisect is making policy
decisions for me. If you think bisects way is right, it seems that
you're the one who has internalized a "solution" that doesn't bug you
anymore. (But perhaps bisect is just a minor point. I tend to get
really annoyed when tools start making policy decisions instead of
providing mechanisms.)
>>> * large/binary files?
>>
>> Don't know. I think the this is an open issue for all VCSs, D or C.
>> Sure I'd like to see it solved, but I don't see that Mercurial has
>> eschewed a solution anyone else is using...
>
> People explicitly shy away from "doing the right thing" about
> putting big artifacts and generated artifacts into their
> repositories because of the drag that puts on continuing development.
>
> As noted above, switching to a multiple clone approach actually
> makes this easy to do and easy to manage over time.
Ok, I'm just not getting it, could you please provide a bit more
concrete of an example? (My apologies if I have missed some email, but
I don't recall seeing enough specific detail to get my head into the
space you are talking from.)
> Sorry, I'm not talking about losing history here. If anything,
> using multiple repos gives more and better history precisely because
> one can and will put more information into those "auxiliary" repos
> and then do whatever HSM (um, er, Hierarchical Storage Management)
> policy that works for you. [Hint: there's an interesting interaction
> here with virtualization, too, for anyone interested but I'll
> refrain from that tangent. :-)]
>
> Multiple repos makes it easier to manage backups over long periods
> of time especially as the repo sizes grow. Sounds like you don't
> have any of those problems yet so no worries.
Maybe I don't yet, but other large open source projects do... What
kind of "more information" are you talking about, you make it sound as
if that extra info isn't normally part of the product/clone/release
whatever...
> You seem to be working under a model in which all of the repos have
> the same intent/rules/etc. Once you get into a situation where you
> can't do that you run into a wall (the simplistic and common example
> is large artifacts but if you have lots of teams and lots of
> products it happens too, for example) where the typical solution is
> to periodically contort your workflows, add hacks to deal with some
> artifacts which are kept out of the repos themselves, etc.
I have no idea what you are talking about here. If I have to repos for
which never the twain will meet, then yes I will never want to share
changesets with them, and in that case I would keep them separate.
That was true back when RCS files ruled the earth, so I don't see how
the option to share changesets and have multiple heads is some how
contorting things. I'm not trying to advocate that there be just one
monster repo for all the projects to share...
> What I'm saying is that, if e.g. Hg added real sub-repo support,
> etc. you'd have just as easy a time as you have now with internal
> branches *and* have all of the benefits of having multiple repos.
Ok, now I clearly have no idea what you mean by sub-repo support.
> Anyways, as I noted before, the one point of contention that I'd
> like people to hear is that there is a cleaner model for dealing
> with the various new problems that people have run into with DSCMs
> that solve them just like clones solve the problem with centralized
> branches. As this is my own personal dream and it has little,
> directly to do with Hg, I will shut up now.
Well I'm still curious, so we can take this to non-list email if
you're willing to keep discussing it...
--Doug
More information about the Mercurial
mailing list