[RFC] SVN repo reorganization

Kevin P. Fleming kpfleming at linuxfromscratch.org
Tue Jul 6 09:48:21 PDT 2004

While I'm thankful for the SVN conversion that Jeremy did, I find that 
the resulting repo structure is not to my liking, and not the best use 
of Subversion. It's confusing to have branches and tags for multiple 
subprojects in the same directory...

I'd like to reorganize the repo as follows:

   |     +---nALFS
   |     |    +---trunk
   |     |    +---tags
   |     |    +---branches
   |     +---users_guide
   |     |    +---trunk
   |     |    +---tags
   |     |    +---branches
   |     +---hackers_guide
   |          +---trunk
   |          +---tags
   |          +---branches
   |     +---LFS
   |     |    +---trunk
   |     |    +---tags
   |     |    +---branches
   |     +---BLFS
   |          +---trunk
   |          +---tags
   |          +---branches
   |     +---syntax_doc
   |          +---trunk
   |          +---tags
   |          +---branches

In this scenario, the "trunk" directory each project would be that 
project's HEAD; there would not be any subdirs within trunk other than 
the project's own contents. The "tags" and "branches" directories would 
continue to have subdirectories for each tag/branch for that project.

This separates each subproject into its own area, with its own tags and 
branches. It also moves the nALFS User's/Hacker's Guides into separate 
directories instead of being underneath nALFS, so they can be 
tagged/branched independently.

I'm willing to do all this "svn move" stuff at the same time I renamed 
all the tags and branches to use proper names, which I was about to do 
until I thought it out...

One downside to this is any SVN working copies you may have will lose 
their pointer to the parent repo. I believe there's a way to fix this, 
but it would be better to just schedule a time for this to be done and 
ensure that noone has pending commits; once the reorg is done fresh 
working copies can be pulled and work can continue.

Comments? I'd like to get this done this week if possible, so when the 
BLFS profile gets tagged/branched some more it doesn't get even more 
intermixed with the other projects.

More information about the alfs-discuss mailing list