Re: [linuxsh-dev] Tree Management Questions

[Jeremy S. <js...@mv...>]

Mitch Davis wrote:

> Greg Banks wrote:
> >
> > Jeremy Siegel wrote:
> > > [...] drop-in trees could be made by simply copying the kernel module
> > > and deleting all the files that weren't needed,[...]
> >
> >   That would be a *really* good idea if we had shell access to
> > the CVS machine at sourceforge.  I don't (offhand) know of a way
> > to copy or remove entire ,v files remotely, but I'd be happy to
> > have someone explain it to me.
>
> I believe the only method is via a support request to sourceforge.
> So as to make things absolutely unambiguous, it might be possible
> to make a shell script containing rm(1)s that they can run after
> cd(1)ing to the relevant repository directory.

So one of the project admins has to make the request?  A diff of
the latest kernel and linux modules produces 1458 lines starting
with "Only in kernel", i.e. files/directories that should be pruned.
I don't know much about CVS repository management; I'd guess
the script would be something like:

    mv linux linux-tmp
    cp -r kernel linux
    rm -rf kernel/.cvsignore
    rm -rf kernel/.gdbinit-dmida
    rm  -rf kernel/.gdbinit-sesh3
    ... (et cetera, et cetera) ...
    rm -rf kernel/scripts/usb
    rm -rf kernel/scripts/ver_linux

Then using normal procedures an admin (or anyone) could add
scripts/tree*link.sh, make the linux-2_4-branch, add the tags,
add the AGAINST-* files, then make the appropriate changes
to ChangeLog and kernel/ksyms.c based on linux-tmp. (The
latter is the only code difference between the branches, but
doesn't seem like it's really needed?)  Then linux-tmp can
be removed, and eventually kernel, w/o (as much) loss of
history.

Do we need a vote or something?  I don't feel that strongly
about whether we should do it or not, but I DO feel that if we
are going to do it, it should be soon... and I'd certainly feel a
lot more comfortable killing the kernel module if I knew the
history were still accessible.

--Jeremy Siegel