Organize (closed)

Restructuring SVN repo to allow tags and branches

Summary

closed
Dec 19, 2006
100%
Apr 15, 2012
Dec 19, 2006 / ganesh
Apr 15, 2012 / pixtur
ganesh
 

Attached files

No files uploaded
 
I'm quite new to the project, but it seems to me that the during the migration from CVS to SVN someone made a mistake. CVS is bit more intuitive than SVN for what concerns tags and branches, in practice branch/tag revisions are sort of meta-properties that you just attach to files. Instead, under SVN, branching/tagging is achieved by copying the file to a different location. This means that you have to have a place to copy the file to! Currently every file is under the repository root, so that make tagging and branching practically difficult.

The recommended db structure described in http://svnbook.red-bean.com/ is the following:
  • streber (root of the project)
    • trunk (folder for current development version)
    • tags (folder for tagged version)
      • v0.0703-stable (example of a tagged version)
      • v0.0710-dev (example of another tagged version)
    • branches (folder for branches)
      • v0.0703-fixes (example of a branch)
I feel it's important that we restructure the repository soon, because we are going to need tags! Trust me. At later stages we might also need branches.

It's going to be less painful than you might think, because copies in SVN are cheap operations that maintains the history. Mainly the operations are:
  • on the server:
    • create folder /trunk
    • copy every file and folder from / to /trunk (except /trunk itself, of course)
    • create folders /tags and /branches
  • on each client:
    • issue a svn switch command to "switch" from / to /trunk (this operation does not retrieve any file and [b]does not overwrite local modifications[/b])
The only problems arise if a client with local modifications forgets to do the switch. In particular
  • a commit will fail with a "file not found" error message: safe, but not very intuitive...
  • an update will succeed: a trunk folder will be created locally, all unchanged files will be removed, all changed files will be left where they are, but will be "disconnected" from svn
Even in these unfortunate cases, no local modification is lost, but the situation might be confusing. So it's important that all team members are informed and do the switch before attempting any other operation.

I know this may be a tough decision. I am quite knowledgeable in this area and can provide assistance, in case we decide to do it.

14 Comments

pixtur:That was pixtur's fault :)

11 years ago

Although I am using SVN I have no idea about what behind the scenes. I knew I wouldn't make it perfect, but anything was better than the non working sourceforge CVS. And since there was nobody to ask...

I am happy to get some help from an expert now. And I am already learned the "Trunk" structure. I think we should do it. Erm, I mean... you should do it. :)

Let's decide for a fixed date (like 4th Januar) and place warnings very prominently at the the project page. Than start to count down a few days before the switch.

ganesh:Good!

11 years ago

Sure, I will do it, no problem. I will be on holiday from Christmas to January 6th, but we are in no hurry. Therefore I would set the date a bit later, like January 11th. Would that be ok? I will prepare some step-by-step tutorial for TortoiseSVN by then.
Putting the warnings on the project page is good, but people might forget when the deadline approaches. Is there a way to send an email to every team member, in addition to the "regular" notifications? If not I think it might be a good feature to add. Of course only project managers/admins would be allowed to do it.

ganesh:Just say when...

11 years ago

Hi Pixtur, I'm back and ready to do it. Just say when...

pixtur:Reply to Just say when...

11 years ago

Hi Ganesh,

I currently have no computer at home. So weekends would not be good. How about comming Wednesday? Janury, 17th?


ganesh:Good for me

11 years ago

Ok, I'll prepare a little tutorial with the instruction for the users. Could you please take care of warning everybody? I'll wonder what would be the right time to do the change... What about 12:00 CET?

pixtur:Reply to Good for me

11 years ago

I will post a new and email the developers.

Thanks for helping out with the documentaiton.
About the time: either very late or very early in the morning.



ganesh:Survival guide

11 years ago (6. update 11 years ago)

Ok, I'll do the change on January 17th early in morning (say 1:00am).

With the correct switch procedure described below, you won't lose any local modification in your working folder.

If you use TortoiseSVN π

  1. right-click on the folder that contains all Streber files and select "Switch. You should see a dialog with the following URL:
https://streber.svn.sourceforge.net/svnroot/streber
  1. Change the URL to
https://streber.svn.sourceforge.net/svnroot/streber/trunk
  1. Press Ok.

If you use command-line Subversion π

  1. open a command prompt in the folder that contains all Streber files
  2. issue the command
svn switch https://streber.svn.sourceforge.net/svnroot/streber/trunk

Things that may go wrong π

  • if you issue the switch command too early: no problem, it will fail gracefully with a "Target path does not exist" message;
  • if you forget to do the switch and issue a commit after the move: no problem, the commit will fail with a "File not found" message;
  • if you forget to do the switch and request an update after the move:
    • if you didn't make local modifications: svn will create a new folder "trunk" and move everything into it
    • if you made local modifications: this case is a bit more problematic, but don't panic, nothing will be lost. Svn will create a new folder "trunk" and get a new head copy of Streber into it. All files that were not modified will be removed. All files with local modification will remain in their place but will be "disconnected" from svn. In order to clean things up you have to manually copy them in the right place. Warning: you also have manually take care of conflicts in case someone else has also modified the file. Be careful.

pixtur:Reply to Survival guide

11 years ago

Do you need additional sourceforge rights for this?

ganesh:

11 years ago

I don't know exactly how your are handling repository security. If you are using the authz_svn_module and you didn't set any special start-commit or pre-commit hook, it will be all right. In fact I just need privileges to create the new folder /trunk and moving everything into it (which is implemented by svn as an atomic copy+delete). I should I already have this privileges, unless you deliberately made it otherwise.
One good thing with the new scheme is that you will be able to give full rights to the tags and branches folders only to trusted people, while keeping the trunk open for read/write to all team members. Cool.

ganesh:Done!

11 years ago

Committed revision 258. Happy branching!

pixtur:Small problem with urls

11 years ago (2. update 11 years ago)

Doing the switch with the suggested URL printed following error:
Error: 'https://streber.svn.sourceforge.net/svnroot/streber/trunk'  
Error: is not the same repository as  
Error: 'https://svn.sourceforge.net/svnroot/streber'  

However, switching to...
https://svn.sourceforge.net/svnroot/streber/trunk

... worked as expected.

Thanks!



ganesh:

11 years ago

Ah! I got that URL from http://sourceforge.net/svn/?group_id=145255. Apparently the "streber." prefix is optional, yet it confuses SVN enough to believe they are two different repositories. It's good you succeeded anyway.

madlyr:We lost SVN - Streber bugID integration after restructuring

11 years ago

ganesh please see and add this feature to current repository, it's very helpful.

ganesh:Reply to We lost SVN - Streber bugID integration after restructuring

11 years ago

Done. I apologize, I believed the bugtraq properties were going to be propagated recursively down from the root folder, but actually it doesn't happen because the root folder is no longer in the working copy. I copied those properties (and svn:ignore too, which wouldn't propagate either) in the trunk folder. Just do an update and everything will be all right.