Update to revision always updates externals to HEAD
Olivier Sannier
I'm using TortoiseSVN 1.9.5 here and am facing a very strange issue when
I use the "Update to revision" option.
What I'm expecting is that my entire working copy is updated at the
revision that I asked for, say 66850 for instance because I did not
check the "Omit externals" checkbox.
However, my issue is that the working copy is updated at the revision
but all externals are updated at the HEAD revision.
And this leads to errors because some externals targets have been
removed in HEAD.
Here are an update log final lines:
C:\Path\To\FirstExternal\SubDir\File.txt
C:\Path\To\SecondExternal
URL
'https://svnserver/svn/Repos/trunk/Some/Where/Removed'
at revision 70574 doesn't exist
At revision: 66850
As you can see, it complains that the path does not exist in HEAD but
still says that the entire update worked on revision 66850.
What am I missing here? Is there some sort of option that I should have
configured?
Regards.
OBones
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3195767
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
Bruce J Clark
That sounds like a classic Subversion issue, rather than an issue with TortoiseSVN. If so, the topic you want to research is Subversion peg and operative revisions. Try looking at the Subversion Red Book (http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html).
Basically, if you want a particular revision of your main repo to extern to a particular revision in another repo, ensure that the external references the revision you want. Typically, you'd want to do that by specifying the peg revision for the extern. If that is done, the update will always update the extern files to the specified revision. If you want the main repo to use a newer revision in the other repo, change the extern to set the new revision and commit the change to the externs.
The error that reports that the location doesn't exist at a particular revision occurs where the extern uses an operative revision rather than a peg revision. The Subversion Red Book explains it better than I can in a single sentence but it's related to how the other repo is searched for the path and revision - the operative revision finds the path and then walks back to the revision; the peg revision finds the repo revision first and then gets the path. If a particular path doesn't exist in the HEAD of the other repo, it can't be found and so can't be "walked back" to the specified operative revision. If the extern is specified as a peg revision, then the search starts at the specified revision, where the path definitely exists.
Hope this helps,
Bruce
This email and any attachments or links herein are confidential and may contain Metrol Technology Limited proprietary information that is legally privileged or otherwise protected from disclosure. It is solely intended for the person(s) named above. If you are not the intended recipient, any reading, use, disclosure, copying or distribution of all or parts of this email or associated attachments or links to other web locations, is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message or by telephone and delete this email and any attachments or links permanently from your system. Metrol accepts no liability for any damage of whatever nature caused by this email.
Hello,
Regards.
OBones
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3195767
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3195771
Olivier Sannier
> Hi,
>
> That sounds like a classic Subversion issue, rather than an issue with TortoiseSVN. If so, the topic you want to research is Subversion peg and operative revisions. Try looking at the Subversion Red Book (http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html).
revision, neither peg nor operative.
This is why I find this behavior quite surprising.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3195772
Bruce J Clark
If neither revision is specified, it is effectively an operative revision of HEAD. In that case, the search starts with the HEAD of the repo, it THEN gets the path. If the path doesn't exist in the HEAD, it won't be found, resulting in a path not found error. The extern needs to start the search with a revision where the path existed - a peg revision can do just that.
I always set the peg revision for my externals to ensure that if I checkout a particular revision of the main repo, I'm always building the same code. Without a specified revision for the extern, checking out the same revision from the main repo at different times will generate different results (because the externs could be different).
As I said, the Subversion Red Book probably explains it better than me, and there's always the risk that I'm wrong. [However, it is based on having a similar issue and trying to overcome it.]
HTH,
Bruce
This email and any attachments or links herein are confidential and may contain Metrol Technology Limited proprietary information that is legally privileged or otherwise protected from disclosure. It is solely intended for the person(s) named above. If you are not the intended recipient, any reading, use, disclosure, copying or distribution of all or parts of this email or associated attachments or links to other web locations, is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message or by telephone and delete this email and any attachments or links permanently from your system. Metrol accepts no liability for any damage of whatever nature caused by this email.
-----Original Message-----
From: Olivier Sannier [mailto:obo...@free.fr]
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3195772
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3195773
Olivier Sannier
Thanks for the reminder, I thus believe that if I use @HEAD on my
externals, this won't solve the issue.
However, wouldn't it be possible to have a special command in
TortoiseSVN that does this? I mean, here are the steps it would do
internally:
Update each external to the requested revision
Update the main working copy to the requested revision, ignoring externals.
I would be nice to have this available instead of having to do it manually.
Regards,
Olivier
Bruce J Clark wrote:
> Hi,
>
> If neither revision is specified, it is effectively an operative revision of HEAD. In that case, the search starts with the HEAD of the repo, it THEN gets the path. If the path doesn't exist in the HEAD, it won't be found, resulting in a path not found error. The extern needs to start the search with a revision where the path existed - a peg revision can do just that.
>
> I always set the peg revision for my externals to ensure that if I checkout a particular revision of the main repo, I'm always building the same code. Without a specified revision for the extern, checking out the same revision from the main repo at different times will generate different results (because the externs could be different).
>
> As I said, the Subversion Red Book probably explains it better than me, and there's always the risk that I'm wrong. [However, it is based on having a similar issue and trying to overcome it.]
>
> HTH,
> Bruce
>
>
>
>
> This email and any attachments or links herein are confidential and may contain Metrol Technology Limited proprietary information that is legally privileged or otherwise protected from disclosure. It is solely intended for the person(s) named above. If you are not the intended recipient, any reading, use, disclosure, copying or distribution of all or parts of this email or associated attachments or links to other web locations, is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message or by telephone and delete this email and any attachments or links permanently from your system. Metrol accepts no liability for any damage of whatever nature caused by this email.
>
> -----Original Message-----
> From: Olivier Sannier [mailto:obo...@free.fr]
> Sent: 02 December 2016 12:59
> To: us...@tortoisesvn.tigris.org
> Subject: Re: Update to revision always updates externals to HEAD
>
> Bruce J Clark wrote:
>> Hi,
>>
>> That sounds like a classic Subversion issue, rather than an issue with TortoiseSVN. If so, the topic you want to research is Subversion peg and operative revisions. Try looking at the Subversion Red Book (http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html).
> Thanks for this, but none of the externals are tied to a particular revision, neither peg nor operative.
> This is why I find this behavior quite surprising.
>
> ------------------------------------------------------
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3195772
>
> To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
>
> ------------------------------------------------------
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3195773
>
> To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3196066
Bruce J Clark
>> However, wouldn't it be possible to have a special command in TortoiseSVN that does this? <<
I don't speak for TortoiseSVN or SVN. I'm just trying to contribute a little back. However, if the option above isn't what you need, perhaps one of the TortoiseSVN contributors might have a comment.
HTH,
Bruce
Hello,
Regards,
Olivier
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3196066
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3196073
Olivier Sannier
>>> Update each external to the requested revision Update the main working copy to the requested revision, ignoring externals. <<
> If I understand your request correctly, I think that's already available. In the TortoiseSVN context menu, there's a sub-menu item labelled "Update to Revision...". One of the options for this command, in the subsequent dialog, is "Omit externals". I expect that this is an option to surface the --ignore-externals option for the "svn update" command. That would allow you to update the main working copy without changing the externals.
>>> However, wouldn't it be possible to have a special command in TortoiseSVN that does this? <<
> I don't speak for TortoiseSVN or SVN. I'm just trying to contribute a little back. However, if the option above isn't what you need, perhaps one of the TortoiseSVN contributors might have a comment.
be at the same revision as the main working copy.
I'll look around to see how to create a feature request.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3196074
Ben Fritz
On Fri, Dec 2, 2016 at 6:59 AM, Olivier Sannier <obo...@free.fr> wrote:
>
> Thanks for this, but none of the externals are tied to a particular
> revision, neither peg nor operative.
> This is why I find this behavior quite surprising.
updating their containing directory to ANY revision will ALWAYS update
the externals themselves to HEAD.
In other words, you're using them wrong, if you want the ability to
check out the externals as they existed at a specific revision of the
containing project. They are acting as designed.
The SVN book
(http://svnbook.red-bean.com/en/1.8/svn.advanced.externals.html) very
explicitly recommends peg revisions for exactly the scenario you're
having trouble with:
> You should seriously consider using explicit revision numbers in all
> of your externals definitions. Doing so means that you get to decide
> when to pull down a different snapshot of external information, and
> exactly which snapshot to pull. Besides avoiding the surprise of
> getting changes to third-party repositories that you might not have
> any control over, using explicit revision numbers also means that as
> you backdate your working copy to a previous revision, your externals
> definitions will also revert to the way they looked in that previous
> revision, which in turn means that the external working copies will be
> updated to match the way they looked back when your repository was at
> that previous revision. For software projects, this could be the
> difference between a successful and a failed build of an older
> snapshot of your complex codebase.
Gavin Lambert
> Thanks for the reminder, I thus believe that if I use @HEAD on my
> externals, this won't solve the issue.
> However, wouldn't it be possible to have a special command in
> TortoiseSVN that does this? I mean, here are the steps it would do
> internally:
>
> Update each external to the requested revision
> Update the main working copy to the requested revision, ignoring externals.
>
> I would be nice to have this available instead of having to do it manually.
externals to their current revision (at the time of branch creation)
rather than continuing to follow HEAD. This is especially useful when
creating release branches.
When you later switch to that branch, they will be updated according to
what had been chosen at the time the branch was created. (And, of
course, any updates made by later commits on the branch, if any.)
In general, "update to revision" should not be something that you're
doing on a regular basis -- it's intended for rare cases when trying to
track down the history of a bug or otherwise make a historic build other
than an active release branch or tag. For things that you are switching
between frequently, use branches.
Also in general it doesn't make sense for "update to revision" to change
where externals are pointing because they're mainly intended to be
pointing at external repositories (hence the name) which have completely
unrelated revision numbers.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3196360