Date: Thu, 20 Jan 2005 13:56:54 +1100
From: Matthew Palmer <mpalmer@hezmatt.org>
To: gnu-arch-users@gnu.org
Message-ID: <20050120025654.GC16408@hezmatt.org>
Mail-Followup-To: gnu-arch-users@gnu.org
References: <41EEECAD.5070705@cfconsulting.ca>
	<20050120001634.GJ16408@hezmatt.org>
	<41EF1351.9050000@cfconsulting.ca>
Mime-Version: 1.0
In-Reply-To: <41EF1351.9050000@cfconsulting.ca>
User-Agent: Mutt/1.5.6+20040907i
Subject: [Gnu-arch-users] Re: Re: Archive configuration recommendations
Precedence: list
Content-Type: multipart/mixed; boundary="===============0251867926=="
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 8907
Lines: 221

--===============0251867926==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oYAXToTM8kn9Ra/9"
Content-Disposition: inline


--oYAXToTM8kn9Ra/9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[Please don't Cc me, I read the list]

On Wed, Jan 19, 2005 at 06:11:29PM -0800, Colin Fox wrote:
> Matthew Palmer wrote:
> | On Wed, Jan 19, 2005 at 03:26:37PM -0800, Colin Fox wrote:
> Matthieu Moy also mentioned mirroring -- but the example in the tutorial
> has "Candice" tagging a branch off the main repository into a local (for
> her) repository.

Tagging and mirroring are basically orthogonal concepts.

> What would the pros and cons be for mirroring vs tagging a single
> project? If my subcontractors mirror, does that mean they mirror the
> whole archive, even if they're only working on one project within the
> archive? If that's the case, it seems like overkill.

Time to do a spot of conceptualisation, I think.

A mirror is a read-only archive which contains the same changesets (and
hence versions, branches, and categories) as a "primary" archive.  It is
typically used to provide read-only access for other people who are unable
(for whatever reason) to access the primary archive.

A tag is a means of saying "this branch here is a continuation of that
branch over there", and in Arch this can cross archive boundaries as easily
as remain within the one archive.

The only way in which mirrors and tagging interact is when you want to tag
=66rom an archive which you can't access directly -- then you instead regis=
ter
the mirror and tag from that.  It's effectively the same archive -- the
ancestry of your tag will list the original archive exactly as it appears on
the other developer's primary archive -- so, for all practical purposes, you
can ignore the mirror issue except when you have to deal with archive
access.

> |>"In ordinary use, you invoke star-merge  in the tree you want to merge
> |>info, providing as an argument the tree you want to merge from:
> |>
> |>
> |>~        % tla get -A candice@candice.net--2003-candice \
> |>~                hello-world--candice--0.1--patch-4 \
> |>~                merge-temp
> |>
> |>~        % tla star-merge lord@emf.net--2003/hello-world--mainline--0.1
> |>"
> |>
> |>What is merge-temp? It's not used in the next command, so what's it's
> |>purpose?
> |
> |
> | There appears to be a missing command there -- between those two tla
> | commands there should be a 'cd merge-temp'.  As per the 'get' docs, that
> | final argument specifies a directory to put the checked-out tree into.
>=20
> Perhaps someone could update the tutorial then -- the one I'm using is

Perhaps someone could.  Best to talk to Tom Lord about that, as I'm pretty
sure it's still his baby.

> the "Arch meets Hello World" tutorial, which is packaged as part of the
> Gentoo tla package (though I've seen the same stuff in the on-line
> tutorials as well).

Well, your first step might be to pest your distribution to update theirs
and push the patches back to Tom.

> |>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 change=
s,
> | 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.
>=20
> 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).

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.

> |>What state is the mainline in
> | Largely irrelevant.  Nothing is changed in the mainline by your merge.
>=20
> Doesn't that depend on the direction of the merge? The remote developer
> is going to need to merge mainline back into his version, and I'm going
> to want to take his changes & merge them back into mainline.

Yes, but you were talking about a single star-merge from mainline to remote=
=2E=20
Later, the mainline developer might star-merge remote back into his mainline
branch, but that then won't modify remote.

It seems like you're thinking star-merge is an inherently two-way operation=
=2E=20
It's not -- each star-merge operator works in only one direction -- pull
changes *from* the branch you specify *into* your local working copy (which
you then commit to your local archive).  The 'star' part of star-merge comes
=66rom the fact that it's intelligent enough to be able to merge changes bo=
th
ways -- but that happens in two separate star-merge commands.

> |>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 th=
en
> | tla star-merge
> candice@candice.net--2003-candice/hello-world--candice--0.1.
>=20
> 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.

> 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
=66rom 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.

- Matt

--oYAXToTM8kn9Ra/9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB7x32BEnrTWk1E4cRAprkAJ9G9uiR2rPF3cZdxHHQcW6FaPy/mwCgiQgG
vHbcFHoYr0YvO1QveWwSy48=
=InCt
-----END PGP SIGNATURE-----

--oYAXToTM8kn9Ra/9--


--===============0251867926==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
--===============0251867926==--