Re: [Gnu-arch-users] Re: DARCS

[Zack Brown]

On Sun, Sep 07, 2003 at 12:16:47PM +0900, Miles Bader wrote:
> Zack Brown <address@hidden> writes:
> > There are also plenty of small projects that don't need the sophistication
> > of tla. Dealing with tla's startup overhead may be fine for large projects,
> > but for a lot of smaller things and single-user projects CVS and Subversion
> > will probably be a lot of users' first choice.
> > 
> > But there are a lot of really big projects out there that would find their
> > entire development model transformed by something like tla.
> > 
> > Also, I suspect that a lot of projects have stayed smaller than they could
> > become, precisely because nothing like tla was available. As amazing as the
> > growth of free software has been, tla offers to bring it to a new
> > level. It's just a different order of organization.
> 
> This is definitely true; what I wonder is, is it possible to make it utterly
> painless to start using arch without introducing obstacles that would make it
> hard for a project to grow later (for instance, the most `initially painless'
> tagging-method in arch might actually be `by name', but that causes obvious
> problems later on)?
> 
> Other than the inventory/tagging-method stuff, what exactly _is_ annoying
> about starting up with arch?  Certainly the necessity of choosing a
> category/branch/version doesn't seem overly onerous -- for most projects
> those things are probably obvious, and it's easy to change them later.

I think the lack of documentation is one of the biggest obstacles right
now. Everything is out of date, and there is not much incentive to work
on the tutorial, because Tom doesn't apply doc patches in a timely way,
and doesn't seem to respond to queries about his invented documentation format.

The tutorial needs to be brought up to date, and a section needs to be
added in the beginning, that explains all the ideas in clear english,
comparing them roughly to existing tools. I envision something beginning
like this:

    The basic data-store in tla is the archive. An archive is like CVS server
    data: it is never edited directly, but users may check out the tree of a
    given project, make changes to that tree, and then check their changes back
    in. Actually, a tla archive is more like a whole group of CVS server data,
    because whenever you start a new project, you don't create a whole new
    archive for it. Instead, you attach your project to an existing archive.
    The only time you are supposed to create a new archive is when the old
    one gets too full or out of date, and you just want to get rid of the
    clutter without losing anything. Then you make a new archive, bring
    (it's called tagging) particular projects you're still working on over
    from the old archive, and then just use the new archive until it fills
    up as well.

With uptodate documentation that addressed people's needs and existing
knowledge, I think folks would no longer have such a weird time trying to use
tla. But lack of understanding is definitely a big part of the overhead of
using tla. Currently if you can't or don't want to read the sources, you're
sol. Reading the tutorial in its current state will only be more confusing,
when a user tries something and it doesn't work.

If Tom would rather do coding, then a great solution (made very easy by tla
itself) is to accept a volunteer as a tutorial maintainer. Let that person
maintain the documentation tree, and let the web-based version be updated
by that person as well. They can then feed Tom the changes and Tom can apply
them at his leisure.

John Goerzen has submitted some tutorial work that has still not been
applied. Why not make him the maintainer, if he's willing?

Be well,
Zack

> 
> I can't offhand think of many problems with tla that don't also exist with
> subversion, etc.  [and indeed setting up a subversion server seems downright
> daunting]
> 
> Certainly the tagging-method question thing seems like the biggest pain.
> 
> Some small improvements might be to:
> 
>   (1) Get the more powerful tagging-method stuff merged
> 
>   (2) ... then make it easy to import .cvsignore files (might be a shell
>       script)
> 
>   (3) Even just make the default =tagging-method regexps cover more common
>       cases, e.g., consider autom4te.cache as junk  :-)
> 
>   (4) Make it very simple to tag an existing source tree for import (with
>       either explicit tags or taglines); I've got my `tla-update-tags' script
>       which tries to do this
> 
>   (5) Maybe make a shell script that automates some of the steps in the
>       tutorial (`Where's your archive located?', `What branch name to you
>       want to use?', ... `I see the following source file types in your tree,
>       and the following unrecognized files... would you like to change
>       something?')
> 
> [Personally I think my own change of removing the `--in-place' option made
> tla about twice as easy to use. :-) ]
> 
> -Miles
> -- 
> 97% of everything is grunge
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/

-- 
Zack Brown