Simple usage pattern seems problematic ?

Maxim Veksler maxim at vekslers.org
Sat Jan 22 06:52:45 CST 2011


Hello,

I would like to ask your advice on our current usage with mercurial.

We've moved from Subversion to mercurial 3 months ago. I was the driving
force of the move: convincing people that DVCS is the right way to go,
choosing mercurial over git and did the initial setup & education.
In the process I've read the whole mercurial book, consulted hginit (by
Joel) and browsed through most parts of the wiki. Based on this input I've
learned mercurial and made an introduction presentation to the dev team.

Today we have ~30 projects, hosted on bitbucket.org. Each mercurial
project correlated to a single software project, most of the projects are
eclipse based so you can think of them as containing a .project in the root
of each mercurial repository.

Our work flow is the most simplistic you can think of. Developer seeking to
make a change to the project checks it out from bitbucket, makes his changes
either using MercurialEclipse 1.7.1 or command line hg which is usually
followed by a commit. Should this be a quick patch change the commit is
followed by an immediate push. None of the projects use "multiple heads" /
tags. All the repositories always remain at default, tip.

The problems:

   - 2 developers working on the same project. Developer1 does a push.
   Developer 2 seeking to apply developer1 changes locally has to follow
   this sequence of actions: (1) pull, (2) update and (3) *merge *followed
   by a (4) commit (of the merge). Please note that I'm not talking about the
   situation where incoming changes cause conflicts (situation which obviously
   requires manual resolution) the described process is for a "clean" update
   where incoming changes can be applied seamlessly.

   Is the described flow normal?
   Is this the expected working method with mercurial?
   Can we have a more simple method to update the local repository without
   having to do merge, commit on each update?

   The merge & commit are specifically problematic because this is reflected
   on the bitbucket diff view, where it shows the developer committing the
   merge as the one actually responsible for the changes, which is obviously
   not the case.

   - Developer can't update his local workspace without committing all of
   his local changes first. Why this constraint exists? The most obvious mode
   where this collides is when you change configuration files for your local
   development... You obviously don't need these changes to be pushed into the
   repository.


These are the main concerns, I would appreciate your input. Please don't
assume basics are clear because I'm getting the feeling we've missed
something fundamental in our work with mercurial.

Thank you,
Maxim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110122/19659c85/attachment.htm>


More information about the Mercurial mailing list