The Latest SVN...

[hybrid]

You know how many external repositories will break by this, you're pretty funny All changes not yet committed (and you know that most people cannot commit on their own) will be hardly transferable.

[anylo]

You know how many external repositories will break by this, you're pretty funny All changes not yet committed (and you know that most people cannot commit on their own) will be hardly transferable.

Maybe I'm bit slow but I really don't see why this would be major issue instead of minor annoyance? Of course it would "break" something but then you'll get ability to use tags and branches.

So, I checked out some version from repository and made my changes

Code: Select all

$ mv irrlicht irrlicht-my-version
$ find ./irrlicht-my-version -name .svn -print | xargs rm -rf
$ svn co https://svn.sourceforge.net/svnroot/irrlicht irrlicht/trunk irrlicht
$ rsync -av irrlicht-my-version/ irrlicht/
$ cd irrlicht
$ svn diff > ../irrlicht-my-version.patch

Or if you have set the irrlicht into your own repository with

Code: Select all

svn propset "svn:externals" "irrlicht https://svn.sourceforge.net/svnroot/irrlicht" ./

then you'll just change it with

Code: Select all

svn propedit irrlicht

Or am I missing something else?

[anylo]

And you can always store your own version into branches before merging it into HEAD.

Code: Select all

$ svn copy ./ https://svn.sourceforge.net/svnroot/irrlicht/branches/hybrid-1.3 -m "Hybrid's version, use with extreme caution"

Anyway, this is just random mumbling and it can be ignored.

Version Control with Subversion - Repository Layout

Of course, you're free to ignore these common layouts. You can create any sort of variation, whatever works best for you or your team. Remember that whatever you choose, it's not a permanent commitment. You can reorganize your repository at any time.

[Saturn]

The amount of "breaking" is not much really. If a file is moved in the repository and an older checkout has a modified version of this file, then the modified file is left untouched and the moved file is copied in the version as found in the repository. So all the user has to do is to move the modified file into its new location himself. Deleted files have to be deleted anew and newly added files have to be reverted and added into the new place.

This all is very manageable. The benefits outweight the costs here.

Btw, changing Irrlicht's interface, which is done often compared to a layout change, breaks code too. And fixing modified code to work with the changes done by the team can take more time than necessary changes due to repository layout changes.

[bitplane]

Will moving all the directories result in losing file history?

Other than that, I think this is a good idea. We should probably set a date for this and warn everyone in advance.

[Saturn]

Will moving all the directories result in losing file history?

No, it will be marked as a copy and what it was originally copied from and history will still show changes done to the file in its old location.

[anylo]

Will moving all the directories result in losing file history?

Nope. Moving files to different folders is just one revision more.

And if something goes wrong, just revert and try again.

[hybrid]

I have currently not too many modified files, so I'd appreciate to move now
The problem with layout changes is that you usually get lots of left files which have to be manually copied over the (possibly already changed) new file positions. For the proposed change it is not that much trouble since the major hierarchy is moved completely. A completely new layout is much more troublesome. Moreover we'd have to lock the repository for some days to avoid unintended overwriting with old files.
Anyway, please don't use the easter holidays for the move ( before would be much better) because much development might happen those days.

[anylo]

Moreover we'd have to lock the repository for some days to avoid unintended overwriting with old files.

Well, not really.

Just create branches directory. Then everyone who can commit changes copies his current work into https://svn.sourceforge.net/svnroot/irr ... /<nickname>. After moving stuff from repository's root directory into trunk you just merge your changes into trunk from your branch.

So, you can safely create the layout

Code: Select all

$ svn mkdir https://svn.sourceforge.net/svnroot/irrlicht/branches/
$ svn mkdir https://svn.sourceforge.net/svnroot/irrlicht/tags
$ svn mkdir https://svn.sourceforge.net/svnroot/irrlicht/trunk

then copy your current work into branches

Code: Select all

$ svn copy . https://svn.sourceforge.net/svnroot/irrlicht/branches/hybrid -m "Personal copy while reorganizing repository."

When every committer has made their own branches (or committed changes into repository) then you'll just move the files/directories into trunk (described in the earlier post). After reorganization you can merge your branch into trunk whenever you have time to do that (use TortoiseMerge or whatever you prefer). And after that if there's no need to use personal branch just delete it.

Code: Select all

svn delete https://svn.sourceforge.net/svnroot/irrlicht/branches/hybrid -m "Merged into trunk."

With this change you can easily maintain different releases, fix a bug in earlier version while developing next one etc.

[vitek]

The other advantage of maintaining branches is that you can have a policy that requires changes to be reviewed by others before they are merged to the mainline. I know that there is at least one developer on the team who doesn't commit changes for a long while, then dumps thousands of lines of code onto the mainline without having to pass it by anyone. A simple branching/merging policy would eliminate this problem altogether.

Travis