Re: [Gnu-arch-users] Utterly painless arch?

[Tom Lord]

    > From: Zack Brown <address@hidden>

    >> a) screwing around with =tagging-method is, indeed, the number one
    >>    problem newbies encounter

    > That's why the default should be something that requires no user
    > action, but just works reasonably; and then if they want better
    > behavior, they should be able to change it later.

What's your opinion about the user-action of `tla add'?  That's about
all that will be required using what I've proposed and, in that
regard, it's the same as CVS.

    > > It's already a pretty small number of commands.    From the traffic
    > > I've seen, the biggest obstacle relates to your observation that
    > > people grab some source they already work with, and try to check that
    > > into arch.   Then they run face-first into the need for
    > > =tagging-method customization and can't get through that wall until
    > > they learn what `inventory' does fairly deeply (and, even then, it can
    > > be awkward for some trees).

    > Again, this is an argument for a tagging default that's transparent to
    > the user. If the inventory stuff is so complicated, then just give sane
    > defaults so the user doesn't have to worry about it. Let them 'upgrade'
    > to more powerful controls later as they get more used to the system.

Well, that's what today's `untagged-source' hack is for.   It will
result in an =tagging-method default setting such that most users
should never need to look at =tagging-method at all.   What they `tla
add' is what's archived, and what they don't is what isn't.

The advantage of this approach over making `names' the default is that
there's no need to upgrade, unless the user wants to use the feature
of not having to use `tla move' when renaming files.


    [re the revision namespace]

    > It's just an additional inconvenience. Before anyone can start to use
    > tla, they are forced to develop a fairly deep understanding of its
    > organizational infrastructure. While this organization may be good, it
    > becomes part of a tla boot-up barrier that can't be avoided.

    > By creating something like name defaults, you give the user the ability
    > to follow the naming conventions when they're ready, but they can also
    > experiment with the tool, without having to understand or be comfortable
    > with the naming conventions.

    > People I've talked to don't only find the naming conventions to be
    > difficult to understand, but they balk at being forced to use a system
    > that someone else thinks is best for them, when they themselves already
    > disagree on the face of it. If you give them time to get to know the
    > tool without imposing that control from the start, they may come to see
    > the value of those controls as they learn how tla is used.

    > I'm really suggesting not abandoning the naming conventions, but just
    > providing a set of defaults that will work without user intervention, so
    > the user will only need to know the bare minimum about those ideas before
    > starting to play around with tla. Once they get the hang of it, they would
    > then be able to start taking advantage of those naming features.

There are certainly ways to hack in this direction.   For example, we
could add a layer of name mangling and a syntax that triggers it --
convenience commands for it -- etc.    If it were a really extreme
issue, we could even take correspondingly radical tack and name
"arch2" that evades the issue.    

The thing is, though, that while you may have talked to people who
pick that issue to gripe about -- a couple of years of experience
suggests that, really, it's not a serious barrier to adoption and does
have plenty of benefits in practice.  So, the utility/cost of trying
to soothe the people you've talked to (about this specific issue)
doesn't look (at least as things stand) very large from over here.

    > I admit I don't really understand the feature you're talking about. But
    > if it would require no user intervention, I'm all for it. As soon as you
    > require that they make some choice between tagging options (or that they 
make
    > modifications to files to adhere to their tagging choices), it seems to me
    > you are requiring them to get to know all the ideas behind those options; 
and
    > that's what I'm suggesting would be good to avoid. 

That's what this change should do, afaict.

-t