apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr-util/test .cvsignore Makefile.in
Date Sat, 02 Dec 2000 16:40:42 GMT
On Sat, Dec 02, 2000 at 04:13:51PM -0000, gstein@locus.apache.org wrote:
> gstein      00/12/02 08:13:50
> 
>   Added:       .        .cvsignore Makefile.in STATUS buildconf.sh
>                         configure.in
>                build    .cvsignore Makefile.in install-sh rules.mk.in
>                include  sdbm.h
>                src      .cvsignore Makefile.in
>                src/buckets .cvsignore Makefile.in
>                src/crypto .cvsignore Makefile.in
>                src/dbm  .cvsignore Makefile.in
>                src/dbm/sdbm .cvsignore Makefile.in sdbm.c sdbm_hash.c
>                         sdbm_lock.c sdbm_pair.c sdbm_pair.h sdbm_private.h
>                         sdbm_tune.h
>                src/encoding .cvsignore Makefile.in
>                src/hooks .cvsignore Makefile.in
>                src/uri  .cvsignore Makefile.in
>                src/xml  .cvsignore Makefile.in
>                test     .cvsignore Makefile.in
>   Log:
>   initial population of the APRUTIL module.
>...

Well... here is the first cut, people. I'd suggest that we tag the apache
and apr repositories with something like "PRE_APRUTIL_MOVE" and then commit
the files into the new tree.

I wouldn't recommend any repository monkeywork, but just committing the HEAD
from the old tree into the new tree. Of course, I'm sure people will have
different opinions here, so we'll probably want a short discussion...

The layout of directories is what I proposed in my email early this week.
The purpose should be reasonably self-evident.

Note that it uses autoconf and libtool. It isn't complicated enough for
automake, so I didn't bother. The build stuff is also greatly simplified
over those in APR and Apache. A single build/rules.mk and teeny makefiles
throughout.

etc etc ... there isn't much there yet, so I'll skip the length
explanations... a quick review should tell you whatever you want.

The big step, of course, is deciding how we'll move files from other
repositories, then going and doing it. Here are the move options, let's see
some voting:

1) copy the ,v files then remove tags on the new files.
2) "cvs add" the head of the old file with a reference to the location/tag

Choose! :-)

[ both options will simply "cvs rm" the files from their old repository ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message