Organize (done?)

Restructuring SVN repo to allow tags and branches / #3488

MoveBookmark

Summary

done?
Dec 19, 2006
100%
Dec 19, 2006 / ganesh
Feb 4, 2007 / pixtur
View previous 6 versions
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 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

Dec 20, 2006
That was pixtur's fault :)
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

Dec 20, 2006
Good!
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

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

pixtur

Jan 10, 2007
Reply to Just say when...
Hi Ganesh,

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


ganesh

Jan 11, 2007
Good for me
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

Jan 11, 2007
Reply to Good for me
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

Jan 13, 2007
version 6
Survival guide
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

Jan 13, 2007
Reply to Survival guide
Do you need additional sourceforge rights for this?

ganesh

Jan 14, 2007
View comment
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

Jan 17, 2007
Done!
Committed revision 258. Happy branching!

pixtur

Jan 17, 2007
version 2
Small problem with urls
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

Jan 17, 2007
View comment
Ah! I got that URL from 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

Jan 21, 2007
We lost SVN - Streber bugID integration after restructuring
ganesh please see SVN integration with Streber as issue/bug tracking system and add this feature to current repository, it's very helpful.

ganesh

Jan 23, 2007
Reply to We lost SVN - Streber bugID integration after restructuring
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.
 
 

Comment / Update