Re: tagging externals

On 03.03.2010 10:51, Robin Guest wrote:
> On 15 February 2010 20:17, RHF <robert.h.fletcher_at_gmail.com
> <mailto:robert.h.fletcher_at_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_at_2620 LoginForm
> ^/Common/Controls/PDFHelp/stable/Classes_at_2620 PDFHelp
> ^/Vendor/Krypton/Toolkit/stable_at_2620 KryptonToolkit
>
> Tagging with build 1.6.99.18790 gives these externals:
>
> -r 2424 ^/Common/Controls/LoginForm/stable_at_HEAD LoginForm
> -r 1991 ^/Common/Controls/PDFHelp/stable/Classes_at_HEAD PDFHelp
> -r 2496 ^/Vendor/Krypton/Toolkit/stable_at_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_at_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]
>

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
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].