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