Message-ID: <41EF1351.9050000@cfconsulting.ca>
Date: Wed, 19 Jan 2005 18:11:29 -0800
From: Colin Fox <cfox@cfconsulting.ca>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041229)
MIME-Version: 1.0
To: Matthew Palmer <mpalmer@hezmatt.org>
Subject: Re: [Gnu-arch-users] Re: Archive configuration recommendations
References: <41EEECAD.5070705@cfconsulting.ca>
	<20050120001634.GJ16408@hezmatt.org>
In-Reply-To: <20050120001634.GJ16408@hezmatt.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: gnu-arch-users@gnu.org
Precedence: list
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: 5099
Lines: 140
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Palmer wrote:
| On Wed, Jan 19, 2005 at 03:26:37PM -0800, Colin Fox wrote:
|
|>The example in the tutorial for using Star-merge is way too short. It
|>seems to assume that the non-mainline developer's archive is in the
|>mainline developer's list of archives, which may not be true
|>(particularly if the developer is developing on a laptop with a dynamic
|>IP). From the wiki:
|
|
| That's where a mirror comes in.  I have a similar situation for myself
- -- I
| hack on my (frequently disconnected) laptop, and then push changes out to
| the mirror on my website for the archives that are likely to be of
interest
| to anyone else.
|
| Your developers could do a similar thing -- have their own private archive
| on their laptops, mirror it to (say) your company webserver (or
intranet, or
| whatever) and then everyone else can register those mirrors and work from
| those.

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.

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.

|
|>"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.

Perhaps someone could update the tutorial then -- the one I'm using is
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).


|>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?

|>What state is the mainline in
| Largely irrelevant.  Nothing is changed in the mainline by your merge.

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.

|
|>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
candice@candice.net--2003-candice/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.
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?

|
|>(Also, there are lots of typos in the wiki -- "..you want to merge info")
|
|
| Feel free to fix up any typos you find.  It doesn't look like they're
| mandating registration for edits yet.
|
| - Matt

It was my mistake -- this is in the "Arch meets Hello World" tutorial,
not a wiki.

Regards,
~  cf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB7xNQoaQ1/feGlJoRAmkkAJ0Tlwgrv+v7MeIW1R7uGP7kX/pu9ACcCo9V
ZlzetdUfKLEJR7E+u7+cTR0=
=dFWs
-----END PGP SIGNATURE-----


_______________________________________________
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/