On 15 February 2010 20:17, RHF <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]
>
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2454365
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-03 10:51:37 CET