On 3 March 2010 18:27, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> 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]
>
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?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2454676
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-04 01:01:39 CET