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

Re: Perl4caml packaged



On Fri, Mar 19, 2004 at 12:14:27PM +0100, Sven Luther wrote:
> > tla id-tagging-method explicit
> > 
> > Then you tla add, tla delete, tla mv, etc. files just like you would
> > with svn.  Or CVS.
> 
> Well, the nice feature we use in subversion is the ability to easily
> 'tag' release, which is extremely difficult and undocumented in arch. 

It's easy but undocumented :-)

First, you set up the mechanism:

mkdir configs
tla add configs

You can then make whatever tree hierarchy you like under configs (making
sure to tla add the dirs as appropriate)

I usually create a file named "latest" for each entry in there.  Here's
a sample from jgoerzen@complete.org--debian:

# arch-tag: config for debian package ocamldbi, latest version
./+packages/ocamldbi/ocamldbi-0.9.3.cvs.52 jgoerzen@complete.org--debian/ocamldbi--debian--1.0

The format is simple: pathname where it should be put followed by arch
version or revision.  This arch revision doesn't specify a patchlevel,
so it always gets the latest on the branch.

Now, let's say you want to checkpoint it.  From the top-level of your
tree, run this:

tla cfgcat -s debian/ocamldbi/latest            (leave off "configs/")

It spits out:

./+packages/ocamldbi/ocamldbi-0.9.3.cvs.52 jgoerzen@complete.org--debian/ocamldbi--debian--1.0--patch-9

Suitable for going into a config file itself.  It looks at the pathname
given in "latest", finds the patchlevel contained therein, and generates
the appropriate config file.

Now, you can run something like:

tla buildcfg debian/ocamldbi/latest

  or

tla buildcfg debian/ocamldbi/0.9.3.cvs.52-1

The files in configs are just like any other; you add them to the
archive, commit them, etc.

A config file is actually more powerful than this.  You can list more
than one entry in the file.  I use that in several of my projects such
as tla-buildpackage.  I have a documentation-building infrastructure
known as sgml-common that I wish to have present in the source trees of
several different packages.  I create a config file for them that has
two entries: the package itself, and one for sgml-common that checks it
out into a subdir of the package.  Thus I can have always-latest
sgml-common in all my packages.  And tla config -s will snapshot *both*
of them so I can recreate the exact tree later.

> > It's never going to be as good as Arch without more support in svn
> > proper, since to be as good as arch, you have to be able to track
> > changes across repositories.  I've spoken to the Svn people about that,
> > and they said "not before 1.0, and maybe not after that."  We'll see.
> 
> 1.0 has just recently been released though, or am i confunding ? 

You are correct.  I was just telling you what they told me.

> > If svn does eventually pick that up, it'd be kick-ass, but it would
> > represent a major change to its workings for sure.
> 
> Or if arch would become more user friendly, that would satisfy the need
> also. Right now you have to go hacking inside some obscure config file
> for it to work well, and the arch people tell me the tutorial is mostly
> obsolet, so ...

The tutorial is old but still mostly usable.  Arch itself is quite
user-friendly; -H is your friend.  I will grant that the
tutorial-related material is lousy and it takes some time to learn how
to put everything together.  But "lousy tutorial" does not equate to
"user unfriendly".

One could argue that it takes a long time to learn the Unix CLI if
you're never used a CLI before.  But it is still quite user-friendly.

-- John



Reply to: