Thanks to Larry, the bkSVN repo is now live. It's actually bkcvs2svn,
since I am using bkcvs's metadata. However subversion is able to make
better use of the metadata than CVS can. You can get better log output,
for one. Also, you can more easily determine the scope of a change,
since subversion supports changesets.
If you aren't familiar with subversion, please visit the URL in my sig.
Please do not ask me a lot of questions about it. First off, it's very
well documented, and second off, I am not what I would consider an
expert on the internals of SVN.
And please DO NOT email linux-kernel with any comments, suggestions,
questions regarding subversion. It is way off topic. Subversion !=
BitKeeper, and it's not intended to replace it. So this isn't a
competition. Otherwise, Larry wouldn't feel so comfortable with hosting
the repo :)
For those that know SVN, you need a recent (e.g. upcoming 0.24 release
of SVN, or current trunk) client. I am using revision r6227. If you need
a client just for testing, you can get a ra_svn only static binary from
http://www.phunnypharm.org/pub/svn/clients/linux/. i386, sparc and ia64
are there. I can build more if needed (I think I have access to just
about anything). You'll need glibc 2.3 for the static clients since it
uses NSS modules, and well, it just wont work with 2.2/2.1/etc. If you
want to build your own, remember, you don't need berkeley DB, or neon
to access this repo.
Now, finally the SVN URL's:
svn://kernel.bkbits.net/linux-2.4
svn://kernel.bkbits.net/linux-2.5
WAIT. If you don't know anything about SVN repo layouts, just remember
this:
REPO_BASE/trunk Primary (aka HEAD) development
REPO_BASE/tags/* Tagged revsions
REPO_BASE/branches/* Other development lines (not used in bkSVN)
So, to get the main development for say 2.5:
# svn co svn://kernel.bkbits.net/linux-2.5/trunk linux-2.5-bkbits
Will checkout the main 2.5 trunk into a directory called
linux-2.5-bkbits. Then you can cd into that directory and do "svn up"
just like CVS :). The "svn log" output is much better than in CVS, since
you can do things like "svn log drivers/usb" and get a single list of
revisions that affected anything in drivers/usb, unlike CVS where you
would get history for all files seperately. "svn help" is really useful
aswell.
If you want to checkout a particular version:
# svn co svn://kernel.bkbits.net/linux-2.5/tags/v2.5.60 linux-2.5.60
Or diff versions, via URL, without a working copy:
# svn diff svn://kernel.bkbits.net/linux-2.4/tags/v2.4.19 \
svn://kernel.bkbits.net/linux-2.4/tags/v2.4.20 > patch-2.4.20.diff
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Sun, 15 Jun 2003, Ben Collins wrote:
> For those that know SVN, you need a recent (e.g. upcoming 0.24 release
> of SVN, or current trunk) client. I am using revision r6227. If you need
Can you confirm that 0.23.0 (r5962) (from Debian unstable) is too old, or is
this a PPC-specific problem?
| callisto$ svn co svn://kernel.bkbits.net/linux-2.5/trunk linux-2.5
| svn: Malformed network data
| svn: Malformed network data
| callisto$
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sun, Jun 15, 2003 at 06:40:46PM +0200, Geert Uytterhoeven wrote:
> On Sun, 15 Jun 2003, Ben Collins wrote:
> > For those that know SVN, you need a recent (e.g. upcoming 0.24 release
> > of SVN, or current trunk) client. I am using revision r6227. If you need
>
> Can you confirm that 0.23.0 (r5962) (from Debian unstable) is too old, or is
> this a PPC-specific problem?
Too old. 0.24 will release with some incompatible revamps to the ra_svn
protocol, but it improves checkout over high latency by a noticable
amount.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
Somehow the logic I had in my python script that was meant to ignore
BitKeeper/* files (not put them in the repo), which worked on the other
two machines I've run this on, seems to be exposing a bug in the python
on kernel.bkbits.net. It did not allow the COPYING file through the
os.path.walk() callbacks, so it was not in the repo as well.
I am not ignoring files anymore...I don't think it hurts anything having
the BitKeeper files. It was only a personal hack I had in place for when
I was using this setup just for myself for the past 3-4 weeks.
Now, Larry and I have our opposing conspiracy theories about why
ignoring the BitKeeper files would cause the GPL license to also be
ignored, but that's a neither here nor there ;)
Fact is, I had to rebuild the repo's. That means a complete re-checkout
for everyone.
Sorry.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/