Strategies for push/merge problem?

[Gábor Farkas]

On Mon, Jul 14, 2008 at 12:24 PM, Roman Kennke <roman.kennke at aicas.com> wrote:
> - Use clones for each separate work. This is kind of difficult, take the
> one-liner as example. Cloning a whole repo takes  ~5 minutes in our case
> (lots of history). So people tend to quickly hack it in an already
> cloned repository and run into the above situation.

this is similar to what our team uses.

generally fixing a "one line" bug works like this:

1. you are currently working on a feature. means you have a clone of the repo,
and developing and committing on it. you do not care about what
happens on the "central server".
you only care about the feature you are currently developing

2. now someone informs you, that there's a bug in the code, which has
to be fixed urgently.

3. you make a new clone of the repo from the server.

4. you fix the bug in the code.

5. you commit the fix to your local clone

6. you push the code to the server

7. you delete this clone where you created the bugfix, and you return to working
on the task. so you basically return to point 1.

8. when you are finished with your task, you push it into the central server.
if it fails (warning about it creating multiple heads), then you pull
all the changes
from the remote-server to your local clone, do a merge, and a push.

9. you delete your local branch

10. you take the next feature you will develop. you make a clone of
the repo from the central server, and go to #1


this is how it's done.
there are many optimalizations to this (to make it faster), but they
require that your developers
really understand how mercurial (or basically a dvcs) works. so at the beginning
imho it's better to keep to this plan.

please note, that in the plan i wrote, we never ever merge that bugfix
into the task you are working on.
this is absolutely fine. after all, they are separate issues.
of course, when you will be pushing your feature into the
central-server, for sure you will have to merge.
but that's ok.

now, some optimalizations that can make things go faster:

A. you can keep a local "copy" of the repo from the central-server.
it's basically a clone,
to which you never commit, only pull. so when you need a copy of the
repo from the central server,
you just update your lcoal-copy (by pulling form the central server),
and then clone from your local copy

B. you do not have to delete your branches. they are simply graphs
made of changesets,
so you can keep them, update them and strip them, when necessary. but
it's usually simpler
to just delete the unneeded ones

C. technically, the whole workflow i described can be done in one
repo. no need to create new repositories.
but then your repo will contain multiple heads, which you will have to
be able to handle, and strip when
needed, and push only certain changesets. some people work like that,
and it's ok, but again,
you need to have a good understanding about how things work in mercurial.
i personally prefer the one-branch-has-one-head approach :)

gabor