RexZhang4321 / tortoisesvn

Automatically exported from code.google.com/p/tortoisesvn
0 stars 0 forks source link

Externals management #476

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
From the mailing list:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=305213
4

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).

Original issue reported on code.google.com by tortoisesvn on 20 May 2013 at 4:20

GoogleCodeExporter commented 9 years ago

Original comment by tortoisesvn on 24 May 2013 at 4:32

GoogleCodeExporter commented 9 years ago

Original comment by tortoisesvn on 25 Dec 2013 at 12:57

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r25079.

Original comment by tortoisesvn on 25 Dec 2013 at 7:32