[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: tagging externals

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Wed, 03 Mar 2010 19:27:44 +0100

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 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 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]

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


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-03 19:28:07 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.