what do I need to learn to do this task?

[Dave S]

On Mon, May 12, 2014 at 6:17 PM, Michael Mossey <michaelmossey at gmail.com>wrote:

> I'm new to Mercurial and I don't have a lot of time to devote to learning
> it (or any SCM system) in great detail, nor do I need to, so I am wondering
> if I could get some guidance about the specific things I need to do this
> task:
>
> I am part of a two developer project, something small and short-term so we
> may not have to branch very much, and I'm using Mercurial to keep us in
> sync. So far all we've done and pushed and pulled from the tip of the
> Bitbucket repo we are using.
>
> I have something else I need to do which may require branching. I work on
> two different computers, my laptop and my home desktop, and a Mercurial is
> the perfect solution for keeping them in sync (as compared to copying files
> back and forth). I don't have to remember which is the last machine I
> worked on, and I don't need to worry if I make changes on both
> machines--Mercurial will help me integrate them. However, I switch machines
> often, so if I push and pull from the central repo every time I do so, I
> will be putting a lot of changesets on it that aren't very meaningful (and
> even probably not functioning).
>
> So I figure that I probably want to do this with a second repo and also I
> want to do it on a branch. But as I barely know anything about Mercurial, I
> don't know how to structure these or what commands I'll be using. I'm
> reading O'Sullivan's book right now, but I would also appreciate tips from
> this list.
>
> My workflow will look something like this:
>
> (1) I'll check out a copy of the main Bitbucket repo
> (2) I'll work on my laptop
> (3) I'll be ready to switch to my desktop, so I'll commit changes
> (3) I'll push changes to some kind of secondary Bitbucket repo
> (4) I'll get on my desktop and pull those changes, and work
> (5) Get ready to switch to laptop; commit changes and push to secondary BB
> repo again
> (6) Continue, creating possibly a dozen small meaningless changesets until
> ready to commit a feature or intermediate feature to main BB repo
> (7) here's the trick I don't understand--somehow push and/or merge my
> changes with the main BB repo, hopefully without pushing a bunch of
> meaningless changesets onto it
>
> So basically I'm wondering how to structure things so I can do (7)
>
> In the meantime I'm reading O'Sullivan's book so I will soon be familiar
> with basic concepts--don't feel a need to explain basics.
> Thanks,
> Mike
>
>
For many purposes, a Mercurial branch and a separate Mercurial repo are
equivalent.   That "many" includes your use-case, I think.  I'd be inclined
to use a named branch, but that's personal preference.

In either case, you would be working in your local repo, checking in and
updating as you go.  At the end of the work session, push from your local
repo to the branch/alternate-repo.  Travel to other machine, and pull from
same.

This differs from your current workflow at the point where you want to
bring some of those changes into the "official" branch/repo.  At that
point, you will do a merge to pick the right mix of "official" and
"alternate"   (Sidenote:  in the book, and in many descriptions here on the
mailing list, you'll see the names "default" and "development" for what I
called "official" and "alternate"; sometimes "feature-name" instead of
"development" or "alternate", especially if "default" is also used for
less-experimental code development).  Doing a merge is a natural thing in
Mercurial, and there's lots of good descriptions of how to do it.

You will also be doing merges from "official" to "alternate" ("default" to
"feature-name") when the code changes in that line of work are needed in
your code base.

I know that I'm being a bit hand-wavy about this, but I think at I'm at
about the right level ("2000 ft view") for your question about workflow.
If you find you need help with the details, fire back with more questions.

HTH

Dave
/dps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140512/9904c18a/attachment-0002.html>