Mercurial in a corporate environment (migration from CVS)
Stephen Morton
stephen.c.morton at gmail.com
Mon Jan 16 17:53:28 UTC 2012
Thanks Angel.
Clarifications below...
On Mon, Jan 16, 2012 at 11:21 AM, Angel Ezquerra
<angel.ezquerra at gmail.com>wrote:
> On Mon, Jan 16, 2012 at 4:43 PM, Stephen Morton
> <stephen.c.morton at gmail.com> wrote:
> > Thanks again for all your feedback and suggestions. I have a couple more
> > questions, below.
> >
> >
> > First a comment. Several people have suggested I use Named Branches. I'm
> not
> > against that idea. In fact in principle I like the idea much better than
> > cloned branches, as it seems more natural and is additionally much more
> like
> > CVS. Really there are two things keeping me away from it.
> >
> > Repository contention. At least in the short term, everybody commits, not
> > designated integrators. Repository contention will be enough of an issue
> as
> > it is, never mind adding 4+ more active release branches to the mix.
> (Even
> > if most merges are on different branches so they're no-ops, people will
> find
> > it frustrating.)
>
> Steve,
>
> I am not sure what you mean by repository contention. Do you mean
> people creating multiple heads? Mercurial tires hard to stop you from
> creating multiple heads _per branch_. You can have as many branches as
> you want. People working on one branch can ignore what people are
> doing on other branches.
>
> Or perhaps you mean people trying to push their changes and not
> succeeding because other people pushed their changes before them? What
> you could call a pre-push pull-merge-pull-merge infinite loop? If that
> is so, this has nothing to do with named branches. People working on a
> branch can ignore people working on other branches.
>
> Still, if that is what you mean, it is a fair question. I must say
> that your best bet is to educate your users. Particularly you should
> try as hard as possible to teach your users to _not_ commit and push.
> That is a classic mistake that DVCS newbies make. You must tell teach
> them that they should commit as much as they want, but that they
> should only push when they are ready to share their work.
>
> One could say that what Centralized VCS users call a "commit", in
> mercurial is a "push". If they understand that, you'll be fine.
>
>
Yes, I'm talking about the "pre-push pull-merge-pull-merge infinite loop".
I had been under the impression that since "a changeset refelects the state
of the /entire/ repository" that a changeset not yet pulled on one branch
would block a push on another branch, even though that doesn't make much
logical sense, I thought that it was somehow architecturally necessary.
But after reading your comments I decided to try it and you're right. A
changeset on one branch does not impact another branch. That is very good
news.
>
> > Designer mistakes. By default, an "hg push" pushes all branches
> (different
> > from git behavior). Designers make enough mistakes like this: "I
> > accidentally committed from workspace A rather than workspace B" and "I
> did
> > commit from the correct workspace, but I accidentally did all my
> regression
> > testing on loads from the wrong workspace so that's why I broke
> regression."
> > that I just do not think it will be a good idea to give people the
> option to
> > accidentally commit to multiple branches. (I'm not saying people are
> dumb. I
> > work with some very very smart people. I'm saying that human nature is
> what
> > it is. And I should design the tools to help people, not to lead them
> into
> > the kind of traps they're prone to fall into.) Though I suppose I could
> > write a hook to prevent a push that contains changesets to multiple
> branches
> > so maybe this isn't a real problem.
>
> I also don't think this is a real problem. Mercurial does not let you
> create branches by accident. It will always assume that you want to
> commit on the same branch as your parent revision. If you try to
> commit into a new or a different branch, mercurial will always ask you
> to confirm that that is what you really want to do.
>
> In consequence, the usual workflow is that you update to some
> revision, usually to the (single) head of a particular branch, do some
> changes and commit. The commit will be on the same branch as the
> parent revision by default. People have to get out of their way to
> commit to a different branch.
>
> So I really don't think you should be very concerned about using named
> branches.
>
I'm not worried about somebody committing to the wrong branch, or that
they'll create a branch.
I'm worried that somebody will have good ready-to-deploy commits on the
Release 2.1 branch, and in-progress changes that do not pass regression
testing yet on the Release 3.0 branch and they will accidentally push them
both.
>
>
> > But I'd be happy if people could convince me otherwise, because in an
> ideal
> > world I'd love to use named branches.
> >
> > And here are some issues that I've run into when actually implementing
> this:
> >
> > Q1. Using the "branching by cloning" method, how do you tell what branch
> > you're working on? If you clone a couple of times and lose your
> > paths.default, how do you even know where a repo comes from? You'd want
> > people, as well as automated scripts, to be able to easily see from a
> > workspace which release it was from. The easiest thing I could think of
> was
> > a .branch file in the workspace root that would be like a CVS/Tag file
> that
> > would contain a short string like "RELEASE 2.0".
> >
> > Another solution might be on release clones, to use a single named branch
> > where all commits would be made. (A hook would prevent commits to
> > "default".) A simple "hg branch" would list all branches and you'd see
> what
> > branch the repository is for.
>
> Q1 -> a good argument in favor of using named branches :-)
>
> > Q2. Suppose you have a small file with many many many revisions such that
> > while the file is small, the revlog is big, very big. If somebody else
> > pushed a modification to this file and I pull to update my repository,
> will
> > my pull transfer a small amount of data, roughly the order of magnitude
> of
> > the change or even the whole file, or a much larger amount of data
> roughly
> > the order of magnitude of all the revlog data? (This may impact whether I
> > need to do some major refactoring of my repository during the conversion
> to
> > Mercurial or not.) I could not find this information in the Mercurial
> > documentation, but somebody's earlier reply
>
> People here can answer you much better than I can, but I think that as
> mercurial deals with "changesets", you'd only get a small transfer,
> containing the changes that you do not have yet in your repo.
>
>
That's what I'd think too. But I'd want to be sure. I can always bring out
wireshark or tcpdump to measure it, but it would be nicer just to find out
from somebody "in the know."
> Cheers,
>
> Angel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120116/e21d5cd9/attachment-0002.html>
More information about the Mercurial
mailing list