To: gnu-arch-users@gnu.org
Subject: Re: [Gnu-arch-users] Archive configuration recommendations
In-Reply-To: <41EEECAD.5070705@cfconsulting.ca>
References: <41EEECAD.5070705@cfconsulting.ca>
Mail-Folloup-To: never
Mail-Copies-To: never
Date: Fri, 21 Jan 2005 13:44:35 -0500
Message-Id: <20050121184435.200FD8146A@comet.merconline.com>
From: jblack@merconline.com (James Blackwell)
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: 5542
Lines: 147
> I've been toying with arch on my own for a while, and I like it (though
> I'm still not sure about the whole pre-punctuation thing - ++ ,, = {}
> etc -- makes some things quite awkward).

They can look annoying, but in practice they're rarely a problem for
most people. Generally speaking, you'll enter {arch} 2 or 3 times during
the entire life of the project (once when you init-tree, perhaps a
couple more times to do fine tuning later). 

Most ++ files (which can be annoying with some editors) are either only
there for a very short lifetime (unless there's a problem), or usually
have some other way to specify the filename on the command line. 

the ,, files actually end up being a *really* nice thing, because I'm
nearly certain that you don't have any files that start with ",,", so
you can blindly go "oh, here's a dir that starts with ,, I don't want,
rm -rf ,,*". 


> Anyway -- I have a small company with 3 subcontractors, and I'll be
> bringing more on this year.
>
> The two methods (as I see it) of archive configuration are (a) One
> central archive that everyone commits to, and (b) one master archive and
> each developer having their own development branches.

You're the cook. Which type of pot you want to cook with is up to you.
:)

> The (a) method is pretty much what we already have with CVS, and it
> works fine.

>
> The (b) method has some definite appeal - I like the idea of developers
> being able to work on their own, with as many commits as they want to
> their own archives before creating a big ball o' changes to go back to
> the main repository.
>
> But I haven't seen enough documentation (or the right docs) for how to
> set up (b). The idea of a non-core OSS developer submitting changes has
> been mentioned, but no detailed cookbook style docs describing how to
> actually do it (well, as far as I've been able to discover, anyway).

This differs slightly between tla and baz in interface and subtly in
backend behavior. You don't specify which one you're using, so I'll tell
you both. 

If baz, you start up the original archive. Then get the other members to
create their own empty archives, and set their default archives. Then,
each guy will do: 


For each subdeveloper: 
Baz
---
baz branch bossarchive/your--proj--0 subarchive/sub--proj--0
baz get my--proj--0 myproj
[hack, hack, hack, commit -s "I did this thing"]
"Hey boss, merge me"
you run baz merge subarchive/sub--proj--0
you hack hack hack commit
he run baz merge subarchive/your--proj--0.

Also, the developers can cross merge without any problems, sort of
actual conflicts.

I've written a bunch of very simple baz minihowtos. they're still a 
work in progress, but they're accurate and pretty simple to understand.
jblack@gnuarch.org--2004/bazaar-docs--initial--1.1. The one in
particular that you'd be intersted in is "Following Tux". You can view a 
current-as-of-now copy at http://howto.gnuarch.org/bazaar/


tla
----

tla tag -S yourarchive/your--proj--0 hisarchive/his--proj--0
tla get my--proj--0 myproj
[hack, hack, hack, commit -s "I did this thing"]
"Hey boss, merge me"
you run tla star-merge subarchive/sub--proj--0
you hack hack commit
he runs tla star-merge bossarchive/your--proj--0

In tla's case, developers can not cross merge (though if you guys are
careful, you can run certain commands like replay). But for the most
part, all merges come/go through you. (I.E. sub1 doesn't star-merge
sub2)

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

Ahh. You're using tla. Forget the following tux suggestion, as it's
reliant upon baz's method of merging.

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

           % cd 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? What happens after the star-merge? What state is the mainline
> in, and what happens when 'candice' wants to re-get the stuff from
> mainline. Does she also star-merge?

There's a command missing in between the two, which I've inserted.

when you run "tla get .... merge-temp", you're saying "get this project,
and put it in the dir called merge temp".
>
> (Also, there are lots of typos in the wiki -- "..you want to merge info")
>
> Any help, docs or pointers greatly appreciated.

Well, they don't strictly apply to tla (they're targed to baz, which has
slightly different commands/arguments etc that act slightly
differently), but baz and tla are both close enough that you should be
able to get a good feel for tla as well by reading them. Well, excepting
for the merge/star-merge stuff. 


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400


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