Message-ID: <4193C7A5.4040001@arbash-meinel.com>
Date: Thu, 11 Nov 2004 14:12:21 -0600
From: John A Meinel <john@arbash-meinel.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
Subject: Re: [Gnu-arch-users] Re: darcs vs tla
References: <20041107234609.7bf0abfe@delta.hk.office.outblaze.com>	<slrncp74m0.ftv.jgoerzen@christoph.complete.org>	<41939CEE.2010409@panoramicfeedback.com>	<20041111174053.GA1818@excelhustler.com>	<4193ACB7.5000004@arbash-meinel.com>	<4193AFFB.9030100@arbash-meinel.com>
	<0D060DE3-341C-11D9-9D7F-000393CFE6B8@spy.net>
In-Reply-To: <0D060DE3-341C-11D9-9D7F-000393CFE6B8@spy.net>
Cc: gnu-arch-users@gnu.org, John Goerzen <jgoerzen@complete.org>
Precedence: list
Content-Type: multipart/mixed; boundary="===============0187862775=="
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: 5079
Lines: 133
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0187862775==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig9ADA22E1CFB65724A3A68CB9"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9ADA22E1CFB65724A3A68CB9
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dustin Sallings wrote:
> 
> On Nov 11, 2004, at 10:31, John A Meinel wrote:
> 
>> Is that very difficult compared with what you do in darcs? Yes, tla 
>> doesn't have this built-in, but it is pretty easy to layer this 
>> functionality on top. And if you convince Tom, you probably could get 
>> a 'tla pure-merge' command that would do the same thing.
> 
> 
>     This is getting more confusing, though.  I already have to use 
> errors to tell me which of update or replay or star-merge is the right 
> way to apply changes between trees.  pure-merge doesn't seem any more 
> descriptive or obvious than star-merge.
> 
>     If darcs wins here because of simplicity, adding complexity doesn't 
> seem to be going in the right direction.
> 
>     I think that's really the point.  darcs has a command to save a 
> changeset in the working tree, and then a few commands for moving 
> changes between trees.  The changes are mostly based on *how* you're 
> moving changes and not so much why or how the tree was branched or 
> whatever.  I.e.:
> 
>     push - push changes from here to another tree (defaults to the tree 
> from which I branched)
>     pull - pull changes from another tree (defaults to the tree from 
> which I branched)
>     send - asynchronously send changes to another tree (i.e. I email 
> patches to a machine)
> 
>     I typically use replay when updating source trees because someone 
> told me it was a good idea a long time ago and it seems far faster than 
> update when it works.  I tend to use star merge when integrating 
> branches, but I've had that fail in such a way that I had to undo and 
> use replay.
> 
>     There was a comment earlier about how you have to understand darcs' 
> concepts of patch theory to use it properly, but it seems to me that 
> arch requires way more understanding than darcs does for normal use.
> 

A agree, it does seem that darcs wins in simplicity, sort of. The thing 
is it doesn't let you do the things that arch lets you.  For instance

1) How do you tell darcs that you want the most recent version of the 
source tree, with the current modifications then applied (meaning the 
archive is more important than my changes. This updates to the latest 
archive version, and then applies my changes.)

    tla update

2) How do you state that my changes are more important. (This applies 
each missing patch until one fails.)

    tla replay

3) How do you say. Well, I've done all these changes on a branch, and 
now I'm ready to commit it to the main branch as one logical merge.

    tla star-merge

4) Each change I just did should be entered into the main branch as an 
individual change set.

    tla pure-merge (theoretical)

I realize tla is not very simple, but some of that is because it lets 
you do complicated things. I completely agree with you that the basic 
interface can be streamlined. Some of that is what the spinoff projects 
are for. You have Aaron's Friendly Arch Interface (fai), or the new 
bazaar (baz), in development.

But a lot of that is just the (superficial) interface stuff. Yes, it is 
very important to make people feel like they can do what they want, and 
to do that you want a reasonable simple interface. But you also don't 
want to make it so simple that nothing can get done. I would argue that 
having darcs take 1 hour to commit a change is plenty of time for me to 
figure out what the difference is between update/replay, and then I 
don't have to worry about it again.

My personal concern with darcs is that patches are a little bit too 
free-form. I should probably go back and use it some more, but having 
patches be numbered makes it very easy to ask the question what is and 
is not in this source tree.

John
=:->

--------------enig9ADA22E1CFB65724A3A68CB9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBk8elJdeBCYSNAAMRAj8TAJ9s2SpuOhWhiOqCSuvo0CxujXTNZACfXwFL
1mO1S+73jLIQVvYzDE0uedM=
=qNYL
-----END PGP SIGNATURE-----

--------------enig9ADA22E1CFB65724A3A68CB9--


--===============0187862775==
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/
--===============0187862775==--