Re: RFD: CVS or Arch?

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> Dunno if I indeed replied to this already, but I've been working a
> little on this front... 
>
> On Wed, 03 Dec 2003, Andreas Rottmann wrote:
>
>> [...] I've started adopting arch for my work on guile-gobject, and now
>> have left the newbie state (at least I think so ;-)) and feel
>> confident enough with it to propose it as primary SCM for the upcoming
>> guile-gnome project.
>
I've now put my thoughts together and have a preliminary proposal up
at http://yi.org/rotty/GuileGnomeArchProposal.html. It would be nice
if we could refine this through discussion until we think its "ready
for implementation". Should I post a text version to the list to ease
discussion?

> I have some practical questions about using it that I'll ask to you on
> the list, because they might be of wider interest once people get going.
>
>  1. I guess all files should have the same id's in each archive (i.e. my
>     gw-glib-spec.scm should be the same as yours). Where would the
>     canonical arch repo be held, so that we can do this properly?
>     I would like for this to be not on an individual's machine, but
>     somehow on savannah or gnu.org. 
>
I think hosting on savannah is not feasible ATM. I don't know about
gnu.org, but it would really be nice to get some space there. However,
the archive can be created "somewhere" (e.g. on
http://people.debian.org/~rotty) and then moved to a central location,
once we are able to get hold of such a place.

>     And when this happens, how do existing repos (mine and yours)
>     change from the old tags to the new?
>
Do you already have an archive?

>  2. I'm having problems with inventories. It could be because my tla is
>     old (1.0.6 -- I'll update as soon as I can, maybe this weekend), but
>     I have problems committing changes when I build in the source tree.
>     I don't want to build elsewhere because to run uninstalled, the
>     bindings need things from both source and build trees, and it's
>     easier if they are the same. But it manifests itself by complaining
>     about each file that's not tagged, and that's a lot. ATM if I want
>     to commit, I have to make distclean first, and that sucks.
>
There is support for per-directory rules via .arch-inventory files, as
well as the {arch}/=tagging-method file. They are a fairly recent
addition, however.

>> * guile-gnome-common: arch category hosting common infrastructure,
>>   such as the autogen-support.sh stuff, common m4 macros and the like
>
> There really isn't all that much here. I would only break that apart if
> it's trivial and doesn't introduce too many problems.
>
Well, in what I have in mind, the build infrastructure plays a role,
since there might be some magic necessary to allow various groupings
of modules into "release" and "hacking" projects,

>> I still have to play around a bit with arch meta-projects, but from
>> what I can see, they are perfectly suited for release managment.
>
> What a nightmare though! Imagine releasing 20 different tarballs. The
> feelings it stirs are not in my heart, they're in my stomach ;)
>
As I've already said, I don't intend releasing every wrapper module as
a separate tarball.

-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!