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

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

Re: [Gnu-arch-users] distringuished branches, Re: distinguished branch n


From: Tom Lord
Subject: Re: [Gnu-arch-users] distringuished branches, Re: distinguished branch name, "clone"
Date: Sun, 9 Nov 2003 07:37:09 -0800 (PST)


    > From: Colin Walters <address@hidden>

    > the certainly majority of people I've helped learn arch have
    > been frustrated by the requisite verbosity. [....]
    
    > One issue is that I have to help a lot of people out with arch, and that
    > involves typing these commands a lot more than I ordinarily would.  So
    > the effect of the verbosity on me personally is magnified
    > proportionally.

But, compared to what?

In all seriousness: the boilerplate lines I've had to use to check out
CVS trees for various projects are not exactly short or high in
mnemonic value.   In shops where I've used CVS, the branching commands
are sufficiently obscure and awkward that they used far less
frequently than branching in arch.   In CVS one nearly never tries to
use multiple archives for a single project.   Unstructured CVS tag
names may be, on average, shorter than arch version names but, at the
same time, especially in busy/active projects, it can be a real chore
to try to figure out what tags are available and what they mean.

In other words, I think that some of the verbosity in arch compared to
what you might expect is simply the result that when using arch, you
tend to be trying to do fancier things with more parameters to choose
from.

As much as I generally shun GUIs, as I've said before, I think an arch
GUI would be a great thing precisely because there's all these
parameters:  substitute passive recognition and mouse clicks for the
long names.



    >> I really think that for both the use cases you have proposed, an
    >> external implementation is the right proving ground for them.

    > Why in the world would this go in an external implementation?  We're
    > talking about probably at most 50-100 lines of code.  This isn't a
    > complex problem, it's mostly an issue of sane defaults.

If we were, that'd be one thing, but in fact we're talking about
highly problematic defaults.   

The star-merge default is problematic at least because it would do the
wrong thing in so many cases.

The mainline default because (a) it assigns an arbitrary,
underspecified meaning to a particular branch name; (b) it couldn't be
applied consistently (e.g., it would make parameters to abrowse
ambiguous).

-t






reply via email to

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