I know some people have been using subversion for some large
repositories so I thought I would ask what methodology have people found
to work best when managing large third party sources and tracking local
changes.
At the moment I have the linux kernel under svn so that I can track
configuration changes plus some local modifications between versions.
The approach I took was to have the following layout.
rep-+-trunk---linux-+-src---<kernel source>
| |
| +-dest---<installable kernel and modules>
| |
| +-Makefile
|
+-imports---linux---<kernel source here>
|
+-tags---linux-+-2.4.18---<kernel source>
|
+-2.4.22---<kernel source>
The imports directory contains the original source code for the kernel
where I did the equivalent of the following
>cd imports
>tar xfvj ~/linux-2.4.18.tar.bz2
>mv linux-2.4.18 linux
>svn add linux
>svn cp linux ../tags/linux/2.4.18
>svn cp ../tags/linux/2.4.18 ../trunk/linux/src
So I have the linux kernel tagged a t2.4.18 and the trunk has a copy of
2.4.18.
I could now work on the trunk and make any changes that were required
and configure.
To upgrade to 2.4.22 I did the following
>cd imports
>mv linux linux-2.4.22
>tar xfvj ~/linux-2.4.22.tar.bz2 (I could have also applied the patches
in turn but I had the full archive)
>mv linux-2.4.22 linux
with a few svn status and find cmds I svn add/rm to get import to be
the 2.4.22 kernel.
>svn cp linux ../tags/linux/2.4.22
Then on the trunk (Assume the repository is at version 15.
>cd trunk/linux/
>svn merge ../../tags/linux/2.4.18@15 ../../tags/linux/2.4.22@15 src
What I am wondering is if anyone has comments on the above layout for
ease of use and space efficiency. I suppose my real question what would
the impact have been if instead of extracting the 2.4.22 version over
the top of 2.4.18 and checking in the differences I had checked it in as
it's own directory and then tried to merge it into the trunk?
If I did check the 2.4.22 code into it's own directory how would I
handle the merging in a way that svn could apply my local changes to the
new source?
Was this the best way to do this or is there a better way?
Currently the linux kernel is the biggest code set that I am tracking
but there are a number of other application that I also have to keep a
modification, and local change history on so I want to pick a repository
layout and methodology that is both space efficient and speed efficient
for svn to work with.
I have to say so far I love svn and as a product I'm recommending it
were ever I can. Keep up the great work.
Ross
PS As an aside issue it took me three days to attempts get the trunk
merged and checked back in due to the 'End of file' bug in the 0.32.1
code. It was not till I upgraded to the 0.33.0 that I actually managed
to get it all working. Good timing on the 0.33.0 release, thanks. Part
of the reason for the time it took was the fact that the repository is
in New Zealand and I'm in Australia on an ADLS line, checking and merges
were taking a few hours each time I tried.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 17 10:16:57 2003