tagging externals

[RHF]

Stefan,

I just checked out the latest nightly, 18591, and was delighted to see
the modifications to support tagging externals. (I have not been
following the discussions on the devel list.)

I tried it out with a sample test case and would like to pass on the
following comments:

(1) It would be VERY helpful if there was a "Check all" button for
selecting the externals to be tagged. Having to manually select a
large number of library routines is inconvenient.

(2) After creating the tag in the repository, I then decided to
checkout a local working copy. It appeared to work as expected,
creating actual copies of all of the externals in the WC. However, it
then continued processing the same files as externals, giving repeated
'External failed - cannot overwrite existing version...' errors. In
the test tags repository, I see that both copies and externals of each
file are present. Did I do something wrong to cause this?

Thanks again for your excellent work.

Bob

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2447767

To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].

[Stefan Küng]

On 15.02.2010 16:18, RHF wrote:
> Stefan,
>
> I just checked out the latest nightly, 18591, and was delighted to see
> the modifications to support tagging externals. (I have not been
> following the discussions on the devel list.)
>
> I tried it out with a sample test case and would like to pass on the
> following comments:
>
> (1) It would be VERY helpful if there was a "Check all" button for
> selecting the externals to be tagged. Having to manually select a
> large number of library routines is inconvenient.

How many externals do you have?

> (2) After creating the tag in the repository, I then decided to
> checkout a local working copy. It appeared to work as expected,
> creating actual copies of all of the externals in the WC. However, it
> then continued processing the same files as externals, giving repeated
> 'External failed - cannot overwrite existing version...' errors. In
> the test tags repository, I see that both copies and externals of each
> file are present. Did I do something wrong to cause this?

Could you provide us with the original svn:external value(s) and the
modified ones? That way I can check what went wrong and how TSVN
modified the properties.

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2447806

[RHF]

On Feb 15, 11:51 am, Stefan Küng <tortoise...@gmail.com> wrote:
> On 15.02.2010 16:18, RHF wrote:
>
> > Stefan,
>
> > I just checked out the latest nightly, 18591, and was delighted to see
> > the modifications to support tagging externals. (I have not been
> > following the discussions on the devel list.)
>
> > I tried it out with a sample test case and would like to pass on the
> > following comments:
>
> > (1) It would be VERY helpful if there was a "Check all" button for
> > selecting the externals to be tagged. Having to manually select a
> > large number of library routines is inconvenient.
>
> How many externals do you have?

22 for my test case. I include my different library source routines
into my projects as externals.

>
> > (2) After creating the tag in the repository, I then decided to
> > checkout a local working copy. It appeared to work as expected,
> > creating actual copies of all of the externals in the WC. However, it
> > then continued processing the same files as externals, giving repeated
> > 'External failed - cannot overwrite existing version...' errors. In
> > the test tags repository, I see that both copies and externals of each
> > file are present. Did I do something wrong to cause this?
>
> Could you provide us with the original svn:external value(s) and the
> modified ones? That way I can check what went wrong and how TSVN
> modified the properties.
>

I am not sure of the best way to do this. I have exported the
svn:externals properties for both the original trunk,
'trunk.svnprops', and the checked out working copy of the tag,
'test1.svnprops'. Should I just send these two files using the Files
'upload new file"?

What I do not understand, however, is why the tagged WC even has
svn:externals set in the properties.
It has the actual local copies and does not need the externals.
By the way, I am not positive, but I believe that I did the tag
starting with a local WC.

Thanks,

Bob

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2447812

[Stefan Küng]

Yes, please do that.

> What I do not understand, however, is why the tagged WC even has
> svn:externals set in the properties.
> It has the actual local copies and does not need the externals.
> By the way, I am not positive, but I believe that I did the tag
> starting with a local WC.

Did it have svn:externals before the tagging?

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2447816

[RHF]

> Yes, please do that.

OK. I sent the two exported properties files.

> > What I do not understand, however, is why the tagged WC even has
> > svn:externals set in the properties.
> > It has the actual local copies and does not need the externals.
> > By the way, I am not positive, but I believe that I did the tag
> > starting with a local WC.
>
> Did it have svn:externals before the tagging?

Yes. The trunk WC has the svn:externals set for the externals that I
use in the project.

Perhaps I am misunderstanding what is supposed to happen here.
When I manually create a tag, I simply remove the svn:externals
property from, say, the trunk WC.
I then create a tag from this WC. Thus the tag itself no longer
includes the svn:properties.
I then revert the trunk, restoring the svn:properties to it.

I guess I was expecting something similar when using the new externals
tagging feature.

Bob

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2447819

[RHF]

Stefan,

I went back and repeated the process, this time creating a tag from
the HEAD revision in the repository.
I then checked out a WC of this tag and it appears that everything
worked correctly. At least there were no errors.

Apparently, when I created a tag from my trunk WC, it actually made
copies of the external files in the repository and also included the
same files as externals. Having both an actual copy and an external
for the same file is the source of the problem.
When I created the tag from the repository HEAD, the files are
included as externals only in the tag repository.

From this I see also that the new process is different from and better
than the manual procedure I described earlier.
The externals revision numbers are stored with the tag properties -
not actual copies of the files themselves.

The only problem I see now is that when creating a tag from the WC,
actual copies of the externals should not be added into the repo along
with the externals.

Thanks again.

Bob

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2447837

[Stefan Küng]

On 15.02.2010 20:32, RHF wrote:
> Stefan,
>
> I went back and repeated the process, this time creating a tag from
> the HEAD revision in the repository.
> I then checked out a WC of this tag and it appears that everything
> worked correctly. At least there were no errors.
>
> Apparently, when I created a tag from my trunk WC, it actually made
> copies of the external files in the repository and also included the
> same files as externals. Having both an actual copy and an external
> for the same file is the source of the problem.
> When I created the tag from the repository HEAD, the files are
> included as externals only in the tag repository.
>
> From this I see also that the new process is different from and better
> than the manual procedure I described earlier.
> The externals revision numbers are stored with the tag properties -
> not actual copies of the files themselves.
>
> The only problem I see now is that when creating a tag from the WC,
> actual copies of the externals should not be added into the repo along
> with the externals.

Does this also happen if you do not check any external in the branch/tag
dialog and then create the branch/tag from the wc? Does it then include
the (I assume) file externals in the branch/tag too?
If yes, then that's a 'feature' of the svn library and I'll have to find
a way around that...

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2447850

[RHF]

> Does this also happen if you do not check any external in the branch/tag
> dialog and then create the branch/tag from the wc? Does it then include
> the (I assume) file externals in the branch/tag too?
> If yes, then that's a 'feature' of the svn library and I'll have to find
> a way around that...

Very interesting!.
I created a third test tag as you suggested. That is, I created a tag
from my trunk wc and did NOT check any of the externals.
The resulting tag in the repo included both copies of the external
files and also the externals.
So even though the externals were not checked, both the files and the
externals were included in the tag.

(And of course checking out a wc of this tag then gives the same
errors that I mentioned in my first post above.)

Bob

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2447862

[Robin Guest]

On 15 February 2010 20:17, RHF <robert.h...@gmail.com> wrote:

> Does this also happen if you do not check any external in the branch/tag
> dialog and then create the branch/tag from the wc? Does it then include
> the (I assume) file externals in the branch/tag too?
> If yes, then that's a 'feature' of the svn library and I'll have to find
> a way around that...

Very interesting!.
I created a third test tag as you suggested. That is, I created a tag
from my trunk wc and did NOT check any of the externals.
The resulting tag in the repo included both copies of the external
files and also the externals.
So even though the externals were not checked, both the files and the
externals were included in the tag.

(And of course checking out a wc of this tag then gives the same
errors that I mentioned in my first post above.)

Bob

Hi Stefan

I've had chance to test this now (nightly 1.6.99.18790). Great new functionality!

I agree with RHF, the Copy (Branch/Tag) form would be be greatly enhanced by adding a Check All option (right-click menu if you want to save screen real estate). One of my test projects has 18 externals, another has 12. It is harder to make sure you selected them all when the list is only 5 high (quite rightly so, as you don't want it to take up huge amounts of space).  

I also love the new the red arrow icon marking externals in the repo browser.

I didn't see the other problems RHF reported, but my tagging process is different. I only use folder expernals, which always point to the same repo (because we componentise the source of common code into small libraries, for inclusion into multiple VS2005 projects). I typically tag from the wc: I check in the final version of the wc to trunk, then add the msi file without committing it to trunk, peg the externals in the wc, then tag including the msi without switching the wc to the tag, then revert the wc back to trunk.

However, the results were still not as a expected. Let me try to explain:

Say my test project originally had these externals, and HEAD was currently 2620:

^/Common/Controls/LoginForm/stable LoginForm

^/Common/Controls/PDFHelp/stable/Classes PDFHelp

^/Vendor/Krypton/Toolkit/stable KryptonToolkit

If I manually tagged following my procedure above, my pegged externals would be:

^/Common/Controls/LoginForm/stable@2620 LoginForm

^/Common/Controls/PDFHelp/stable/Classes@2620 PDFHelp

^/Vendor/Krypton/Toolkit/stable@2620 KryptonToolkit

Tagging with build 1.6.99.18790 gives these externals:

-r 2424 ^/Common/Controls/LoginForm/stable@HEAD LoginForm

-r 1991 ^/Common/Controls/PDFHelp/stable/Classes@HEAD PDFHelp

-r 2496 ^/Vendor/Krypton/Toolkit/stable@HEAD KryptonToolkit

But this doesn't take into account that the location of the externals could later move. Let's say ^/Common/Controls/PDFHelp moves to ^/Libraries/MyNewCommercialToolkit/PDFHelp in revision 3000, then we check out the original tag when the repo is at revision 5000 and try to work with it:

Loooking at "The Peg Revision Algorithm" sidebar in http://svnbook.red-bean.com/en/1.5/svn.advanced.pegrevs.html:

OPERATIVE-REV [1991] is older than PEG-REV [HEAD is now 5000],so follow the first procedure.

1. Locate item [^/Common/Controls/PDFHelp/stable/Classes] in the revision identified by PEG-REV [which is HEAD, now 5000]. Whoops item doesn't exist here anymore. 2. Fail.

3. Fail.

Whereas if the original tag's external had been:

^/Common/Controls/PDFHelp/stable/Classes@1991 PDFHelp

we get:

OPERATIVE-REV [not specified, implicitly the same as PEG-REV=1991] is the same as than PEG-REV [1991], so we can follow the first procedure again.

1. Locate item [^/Common/Controls/PDFHelp/stable/Classes] in the revision identified by PEG-REV [1991]. Found, because we're before the rename!

2. Trace the object's history backwards (through any possible renames) to its ancestor in the revision OPERATIVE-REV. Well we're already at the right revision, so no tracing needed. Traced.

3. Perform the requested action on that ancestor, wherever it is located, or whatever its name might be or might have been at that time. Success.

I've tested these two scenarios through on a scratch repo, and indeed mine succeeds while yours fails with:

External failed: C:\tmp\pegtest\badpeg\PDFHelp  

Error: File not found: revision 5000, path '/Common/Controls/PDFHelp/stable/Classes'  

Summary:

When you fix the externals during the Copy (Branch/Tag) routine, instead of:

-r [last-changed-revision] [repo-path]@HEAD [wc-path]

use:

[repo-path]@[last-changed-revision] [wc-path] 

 

[Stefan Küng]

On 03.03.2010 10:51, Robin Guest wrote:
> On 15 February 2010 20:17, RHF <robert.h...@gmail.com

But
[repo-path]@[last-changed-revision] [wc-path]
would always check out the HEAD revision. The peg revision only helps to
track renames/moves. But without the '-r' switch, the revision to fetch
defaults to HEAD.

So to fix this correctly, I have to change the externals to
-r [last-changed-revision] [repo-path]@[last-changed-revision] [wc-path]

Of course, the peg revision should only be changed if it wasn't
specified before.

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2454550

[Robin Guest]

Ah yes, I agree.

 

Of course, the peg revision should only be changed if it wasn't
specified before.

Yes, of course.

Thanks Stefan!

Will the new feature make it into 1.6.9, or 1.7.0?

[Stefan Küng]

On 04.03.2010 01:01, Robin Guest wrote:

> But
> [repo-path]@[last-changed-revision] [wc-path]
> would always check out the HEAD revision. The peg revision only helps to
> track renames/moves. But without the '-r' switch, the revision to fetch
> defaults to HEAD.
>
> So to fix this correctly, I have to change the externals to
> -r [last-changed-revision] [repo-path]@[last-changed-revision] [wc-path]
>
>
> Ah yes, I agree.
>
> Of course, the peg revision should only be changed if it wasn't
> specified before.
>
> Yes, of course.
>
> Thanks Stefan!

You can try a nightly build and see if it works for you now.

> Will the new feature make it into 1.6.9, or 1.7.0?

This won't get into 1.6.x but only in 1.7.0. No new features get into
the stable (1.6.x) branch.

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2455192

[RHF]

Stefan,

I just installed nightly release 18808. Thanks very much for adding
the "Check: All" option to the externals tag list. That helps a lot.

I guess I should mention that I still have the problem described
earlier when creating a tag from the working copy. Both actual copies
and external references are placed in the repository, causing an error
when the project is checked out.

This is not a big deal for me since I usually create tags from the
repository HEAD, and this works properly. I just thought you might
want to know about the problem

Bob

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2455499

[Stefan Küng]

On 05.03.2010 16:48, RHF wrote:
> Stefan,
>
> I just installed nightly release 18808. Thanks very much for adding
> the "Check: All" option to the externals tag list. That helps a lot.
>
> I guess I should mention that I still have the problem described
> earlier when creating a tag from the working copy. Both actual copies
> and external references are placed in the repository, causing an error
> when the project is checked out.
>
> This is not a big deal for me since I usually create tags from the
> repository HEAD, and this works properly. I just thought you might
> want to know about the problem

http://subversion.tigris.org/issues/show_bug.cgi?id=3589

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2456128

[Robin Guest]

On 4 March 2010 21:16, Stefan Küng <torto...@gmail.com> wrote:

>     So to fix this correctly, I have to change the externals to
>     -r [last-changed-revision] [repo-path]@[last-changed-revision] [wc-path]

You can try a nightly build and see if it works for you now.

I just tried 1.6.99, Build 18842 - 32 Bit -dev, 2010/03/07 19:58:30, but the externals are still changed to

 -r [last-changed-revision] [repo-path]@HEAD [wc-path]

The Select All/None is perfect.

[Stefan Küng]

On 08.03.2010 10:40, Robin Guest wrote:
> On 4 March 2010 21:16, Stefan Küng <torto...@gmail.com

> <mailto:torto...@gmail.com>> wrote:
>
> > So to fix this correctly, I have to change the externals to
> > -r [last-changed-revision]
> [repo-path]@[last-changed-revision] [wc-path]
>
> You can try a nightly build and see if it works for you now.
>
>
> I just tried 1.6.99, Build 18842 - 32 Bit -dev, 2010/03/07 19:58:30, but
> the externals are still changed to
> -r [last-changed-revision] [repo-path]@HEAD [wc-path]

Fixed in r18876.

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2457235

[Robin Guest]

On 9 March 2010 22:12, Stefan Küng <torto...@gmail.com> wrote:

On 08.03.2010 10:40, Robin Guest wrote:
> On 4 March 2010 21:16, Stefan Küng <torto...@gmail.com

> <mailto:torto...@gmail.com>> wrote:
>
>      >     So to fix this correctly, I have to change the externals to
>      >     -r [last-changed-revision]
>     [repo-path]@[last-changed-revision] [wc-path]
>
>     You can try a nightly build and see if it works for you now.
>
>
> I just tried 1.6.99, Build 18842 - 32 Bit -dev, 2010/03/07 19:58:30, but
> the externals are still changed to
>   -r [last-changed-revision] [repo-path]@HEAD [wc-path]

Fixed in r18876.

Stefan

Just to confirm this is working as expected in TortoiseSVN-1.6.99.19285-dev-win32-svn-1.6.10-dev. Sorry for the big delay in testing this. Thanks Stefan!

Robin