?HowTo commit version when unconnected ? or 2 stages versionning...

[berna...@gmail.com]

Hello, thanks for this list. I am an happy user of tortoiseSVN and i have a request.

I am using a central SVN server, not connected to internet.

But i work sometimes far away, where i do some builds that normally i should commit if connected.

How would it be possible :

 1- to commit some "local versions" to keep track of the versions i need,

 2- to commit these local versions on the central server when i come back to the central connection.

It could mean to have a 2-stage server, a local server to make the logical version, and the ability to commit the local server versions to the central server...

Any idea on that need for "intermittent connection" version management ?

I tried to look for this subject before but found nothing.

Thanks a lot!

[Bruce C]

Hi.

As you'll no doubt realise, your request indicates functionality that is available with a distributed version control system, such as git.

If it isn't an option to switch the overall version control system, you could consider using git locally and then integrating with Subversion. As I understand it, while unconnected you can commit the changes to the local git repository and then use those commits to generate Subversion commits when you're connected again. You might want to investigate the git-svn tool. I don't do this but I expect you can do a little reasearch to identify the advantages and disadvantages.

Another possibility is to use patch files. If you makes changes to the working copy, TortoiseSVN has an option to create a patch file that captures those changes. You could use that capability to capture a potential commit. Then continue to develop and create another patch file to capture the next potential commit. The second patch file will capture the changes from both sets of changes. Later, when you're connected, you can apply the patch files, one at a time, in the order that they were generated. The duplicate changes captured in the second patch file are likely to be ignored when the that patch is applied.

This last option does need careful management. Firstly, I don't believe it doesn't capture changes to binary files. [N.B. It'd be great if it captured the whole of the modified file.] Secondly, cumulating the changes in multiple patch files might have issues where your offline changes add and remove bits from the same sections in the same files. It may still be workable but I expect that you'll really need to understand how it's working to completely avoid issues. Perhaps you can try experimenting and see what works for you.

These are simply suggestions for you to investigate and determine, for yourself, whether they are applicable. I use patch files - but not for this purpose, but I don't use the other approaches.

Perhaps others will have better suggestions.

Good luck.

[Bernard]

Thank you Bruce, very clear, exactly the hints i was needing.

I thought about making the diff manually, but i did learn programming in order to avoid repetitive tasks ;-)

As a matter of fact. i think that a 2 stage process would be very useful in SVN to make the synthesis of both worlds (git vs svn). Automating the diff process is already the basis of svn. Just that it would be necessary to manage a graph of versions instead of a simple tree, with merging between graph paths.

Thanks a lot!