Re: [Gnu-arch-users] Re: Re: Archive configuration recommendations

[Zenaan Harkness]

> > |>What happens after the star-merge?
> > |
> > | The set of changes between the current working copy and the specified
> > | revision (hello-world--mainline--0.1--patch-<last>) is calculated, and
> > then
> > | applied to the current tree.  You should then review the applied changes,
> > | fix any conflicts, and then commit those changes to your tree, thus
> > | completing the merge.
> > |
> > | Caveat: Don't do a merge into a tree with uncommitted changes.  It can be
> > | done, but it's a bit messy.
> > 
> > I'm sorry, I'm still trying to get my head around certain concepts. What
> > do you mean by "merge into a tree with uncommitted changes" -- Is this
> > referring to a remote developer who has made some (uncommitted) changes
> > to his local version and is about to star-merge the main version into
> > his? Or something else?
> 
> OK, let's say I have two branches, trunk and feature.  I initially created
> feature by tagging from trunk--patch-1.  Since then I've updated trunk up to
> maybe patch-4, with some minor bugfixes.  Now I'm working in feature, and
> decide I want those bugfixes from trunk.  I can easily do this:
> 
> tla get feature feature
> cd feature
> tla star-merge trunk
> 
> And the new patches (patch-{2,3,4}) will flow in from trunk, and be applied
> to my working copy.  Those changes aren't *really* in feature, though, until
> I commit the changes that were applied as part of the merge (and so creating
> a feature--patch-n revision containing those changes).

There is a concept that is still not clearly identified here, which took
me a little while to get used to, when I started with arch:

Working directory/ working tree/ temporary dir/ working copy.

I mostly prefer the term "working tree" for some unknown reason.

So, the above command sequence might be better understood as:

 tla get feature feature-wt
 cd feature-wt
 tla star-merge trunk
 # review + fix merge conflicts etc
 tla commit

And at this point the archive version called "feature" has the
new changes from the "trunk" version.

It's vital to understand that there is an archive that you can 'get'
and 'commit' to, 'tag' from etc., and that this is quite different
from a working tree, obtained with a "get" command.

A working tree is so simple that you can copy an existing working
tree too.

And a working tree is where you go to develop, or merge changes from
other trees into yours. Once merged, commit actually commits to your
archive, which in a properly distributed setup is different from the
central/ team/ release archive, it is in fact local to you personally.

> If I've been working on feature for a little while, and then run my tla
> star-merge command, the changes that will be sitting in feature will be my
> uncommitted changes PLUS the changes introduced by the merge, and things
> will get icky.
>
> The way to solve the problem is to either commit before merge, or undo your
> local changes, merge, commit, and redo your changes back onto your tree.

tla undo and redo are very funky commands. Though I do look forward to
the "inline diff markers" (star-merge --three-way equivalent option).

> > |>and what happens when 'candice' wants to re-get the stuff from
> > |>mainline. Does she also star-merge?
> > |
> > | candice just got stuff from mainline in the previous commands.  If she
> > wants
> > | to merge again, she re-runs the exact same command, and tla is clever
> > enough
> > | to work out what to merge and what not to re-merge.
> > |
> > | The alternate action, where mainline wants candice's changes, is a
> > | star-merge again -- this time, we get hello-world--mainline--0.1 and then
> > | tla star-merge
> > address@hidden/hello-world--candice--0.1.
> > 
> > Ok, that makes sense. The only thing is -- I don't want to have to
> > register an archive for each developer so I can get their changes back.
> 
> Why not?  It's not as though you have 150 developers to coordinate.  It
> seems like a lot of hassle, but it's actually really straightforward.

Ack! Register them all - and after some time you may find (as I have)
that people end up with more than one archive. At a small team size at
least, it's not the slightest concern at all.

> > Matthieu Moy mentioned using 'tla delta' and emailing the changes. This
> > sounds like it would work better with my setup, but I haven't read
> > anything about tla delta. It sounds interesting. Any directions on how
> > to use it in a distributed development structure like this?
> 
> Pretty much just as Matthieu wrote it -- a developer runs tla delta <first
> revision> <last revision> and e-mails the resulting changeset in a tarball
> somewhere.
> 
> Another option which I haven't seen mentioned yet is to use a Patch Queue
> Manager (pqm) to handle the management of your integration branch.  In this
> setup, your developers (again) each have their own local archive, but don't
> need to mirror their archive, instead they submit (usually via e-mail, I
> believe) the changesets they want to merge into the mainline to PQM.  It
> then merges the changeset, runs any unit / regression test suites you might
> want, and reports back the results (merged OK / conflicts / test failure /
> whatever).  Your developers will still periodically update their local trees
> from the PQM-managed branch, to ensure that their changesets will still
> apply to mainline.
> 
> The PQM option is documented to some degree in the wiki, and there are lots
> of past threads here on it.  I haven't had the need to use one myself, but
> it's a very, very cool idea.

'Tis indeed. Aegis also features this, and for many years. Arch adds "by
design" distributed architecture, fantastic branching and rock solid
'star-merge' style merging.

Aegis possibly has a little "business process" gold yet to be mined,
although it's relatively minor (I think) given the capabilities of
arch's branching and distributed development facilities...

HTH
Zenaan