gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] distinguished branch name, "clone"


From: Robert Collins
Subject: Re: [Gnu-arch-users] distinguished branch name, "clone"
Date: Sun, 09 Nov 2003 12:05:53 +1100

On Mon, 2003-11-10 at 11:15, Colin Walters wrote:
> On Sat, 2003-11-08 at 18:34, Robert Collins wrote:
> 
> > what about tla get foo<tab><tab> ? That exists today.
> 
> But it's not the same thing.  And besides, we can't just require
> everyone to use completion.  I bet that the percentage of CVS users who
> do is less than 10%.

And? Comparing arch UI to CVS UI on the basis of branch name length
isn't a compelling reason to say that CVS has got it right. Perhaps less
than 10% of CVS users use completion because less than 10% of CVS users
are more than novices?

> > I don't think this is appropriate. One of arch's strengths is it's great
> > flexability. If I chose to use mainline for only production integrated
> > changes (which is similar to what I use HEAD for in some CVS projects),
> > then this wouldn't reflect the latest development. 
> 
> That's fine, but I think that's just you using CVS in an unusual
> fashion.

Not really. There are two common idioms I've encountered with CVS:
HEAD as unstable with branches being stabilised and released.
HEAD as stable with branches for experimentation and another set of
branches for releases.

> But that forces everyone to use configs.  Configs are cool, but they're
> a fairly heavyweight solution; you're solving the problem of requiring
> too much typing by requiring MORE typing.

Sorry, I missed something. I thought you where talking UI sensibility -
the amount of typing is hardly an issue AFAICT. You are either working
in a GUI - which should be aiding you, or you are working in a shell -
which is able to automate as much as you want, trivially.

>   To use configs, a user has to
> go and set up a whole new category and create all these separate files
> and directories. 

Nope. Minimally, create one file with one line in it.

>  If I want to just stick a few files in revision
> control (like say a school project), it feels like a lot of overkill. 
> And I think that's still true even for larger projects like Rhythmbox,
> we only really have one category.  Using a config would force everyone
> to go through the indirection of:
> 
> tla get address@hidden/dists--mainline--0
> cd dists--mainline--0
> tla build-config rhythmbox/mainline

There is a proposal around somewhere to have a default config in a
archive. That would make it:

tla get address@hidden/dists--mainline--0

as the entire thing.


> And then they have this whole other directory lying around, which they
> have to update and manage, etc.  It's much nicer to just say:
> 
> tla get address@hidden/rhythmbox
> 
> And be done with it.

Which then leaves the other management issues you have - changing of
versions and the like up to either manual reconciliation, or unneeded UI
changes - because you aren't using the features designed to handle this.

> > , or the
> > tla grab approach.
> 
> How would tla grab solve this?  I don't quite understand grab.

Think of it as a config with location placed on a website. Then the user
just does tla grab http://www.rhythmbox.org/mainline.tla

> > need is a) more automatic completion 
> 
> It's again not just that - we want a distinguished branch so that people
> can distinguish it.

Huh? We want a development branch so that people develop on it? Use your
website. Use whatever mechanism you use to tell people where your
archive is to tell them what branches are around.

> > and b) iteration 
> 
> Iteration?

Iteration. Go look at the examples you provided - you are iterating over
multiple categories and branches. Definately not core to tla, and I'd
resist it's inclusion unless it shows itself as a killer feature.

Rob
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]