From: REYNOLDS, Dylan <DYLAN.REYNOLDS_at_airbus.com>
Date: Thu, 28 Mar 2013 16:36:06 +0100
One issue I am constantly fighting when using pegged externals is when you have a project folder which contains several pegged external library folders that you are working on:
Imagine you start with all externals pegged to the latest revision for that library (basically at HEAD). When you edit the files in the library your project will function as if it is the HEAD. However, once you commit your changes to the external folder you must then realise that your project is actually now "old" because the external the project folder is pegged to not now the HEAD. Hence, in order to fully update your project to HEAD you have to edit the external reference in your project folder. If you do not when you update your project it will "update" your library back to the pegged external.
With libraries it could be argued that you shouldn't be editing the library while building a different project, although in many work systems you do this. We have a similar but different situation where we want to create specific folder structures and we need to record the exact configuration of these folder structures for historic reasons but also work on them at the same time. To do this we use pegged externals.
Hence, when I edit a file in one of the pegged external folders and then want to commit this file I will then have to go up a level to the "project" or "parent" folder and update the external peg version, update and then commit this. Finally I am now back working at the "HEAD" revision of the project folder.
I realise this is an issue with the way SVN externals work and I am not sure what the solution could be.
However, I thought that TSVN may offer a way around this problem
It could be possible that TSVN peeks to see if a folder is an external to the level above when you commit (perhaps even a property could be used to trigger this "peek" - like a property that says "I could be an external please check"). If TSVN identifies that this is an external folder it could then ask the user whether they also wanted to update the external reference in the parent folder (under the hood this has commit the external folder, get the new repo revision and then update the external peg to this revision). It would then prompt to update your parent folder to bring in the new external. Upon completion of this update it could finally ask you if you want to commit the parent folder, although this might be a step too far. At least up to this point your checkout is now back at the working HEAD revision (but importantly for me the exact actual revision number is still recorded in pegged externals).
I realise these are some pretty complex operations that I am trying to streamline.
Any help very much appreciated.
This e-mail and any attachment may contain confidential and/or privileged information. If you have received this e-mail and/or attachment in error, please notify the sender immediately and delete the e-mail and any attachment from your system. If you are not the intended recipient you must not copy, distribute, disclose or use the contents of the e-mail or any attachment.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
This is an archived mail posted to the TortoiseSVN Dev mailing list.