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

Re: Checkout menu item missing bug, and a couple questions

From: M. Z. <Ziggyesque_at_hotmail.com>
Date: Thu, 20 Nov 2008 21:28:48 -0800 (PST)

Hello Stefan,
Sorry, some other matters came up so just getting back to this, plus
did some research.

By 'default dirs' I mean the entries that get filled into the Repo URL
and Checkout Dir
edit fields. When you use Checkout... from Explorer on a non-WC dir
and then use the
Repo-Browser button to pull up the Repo-Browser, dialog version, to
select a branch
or tag it will modify the Checkout Dir to append the name if it
doesn't already match.

When you go straight to Repo-Browser from Explorer, then try to
Checkout... from there
the Checkout dialog's Dir field isn't primed with the directory you
invoked the RB from,
modified similarly if the repo dir name you're trying to checkout
doesn't match, but
with the last checkout dir used, whether it matches or not. When you
use the Checkout
Dir browse button to reselect the root dir you wanted, you need to re-
open the Repo-
browser and re-select the repo dir to get it to check if the dir names
are the same or not,
or copy/paste the tag from URL edit box to the Chk Dir box.

This also occurs when browsing from a depth=empty dir and you try to
checkout, it
also defaults to last checkout dir, not a level matching what dir
you've cherry picked
applied suitably to the dir you right-clicked to open the Repo-
Browser. While this may
be what was intended to ease creating nested layouts for some people,
I think most
would expect that when the Repo-Dir and the WC-Dir have a common root
that it
wouldn't nest, just be a sparse copy.

Given this behavior for Checkout, I was surprised that Update to
Revision... actually did
function, creating depth=empty intermediate dirs if required. I
haven't tried switching
to a different repository once browser open and then doing an Update
to Rev..., or
other forms of stressing it, though.

As to the research, except for not finding yet the method needed for
QueryRepoVersion,
a patch for the SVN.cpp and SVN.h files should be forthcoming for the
checkout speedup.
It's not a trivial amount of copy/paste, true, but the other logic is
in there and doesn't
need to affect any other files, it appears. Problem is, seems you have
to infer the server
version from the repository capabilities; there's no direct client
call, that I see, that filters
through the RA layer. Should I post it here or to the dev list when
it's done? I don't have
the full VS08, so someone else would have to test it, but I'll try to
keep the typos to a
minimum.

Mark

On Nov 11, 4:44 pm, Stefan Küng <tortoise..._at_gmail.com> wrote:
> M.Z. wrote:
> > Thank you for the quick reply, Stefan. Reply interleaved below.
> > ------------------------------------------------------------------------------------------------------------------------------------
>
> >> M.Z. wrote:
> >> > When you've checked out an empty subdir using 1.5.X's files and dirs
> > ---
> >> > branches subdirs.
>
> >> To cherry pick other folders for checkout:
> >> * right-click on the checked out folder
> >> * choose "repository browser" from the menu
> >> * select the folder you want to add
> >> * right-click, choose "checkout"
>
> > Tried that, sometimes errors out with directory not empty type of
> > errors, and doesn't
>
> I need exact error messages.
>
> > have the same default dirs behavior as the WC side commands do. I
> > haven't saved
>
> What do you mean with "default dirs behavior"?
>
> > exact occurrence data so won't file a specific bug report on that.
> > Besides, that's
> > more a workaround, IMO, than what someone could reasonably expect to see as
> > the behavior of the explorer right-click menu now that the depth option
> > is there.
>
> Problem is: you *can* checkout a subfolder into an already versioned
> folder. But that won't do what you expect: it will create a nested
> layout in your working copy.
> To get subdirs from sparse checkouts, the correct command is "update",
> not "checkout". That's why this is done in the repository browser.
>
> btw: I mentioned before that you should use "checkout" from the
> repository browser, that's not correct. You have to use "update item to
> revision".
>
>
>
> >> > Any possibility the Checkout and Update to Revision ops can be modified
> > ---
> >> > request to the repository, as it appears to be implemented now.
>
> >> That's the behavior of the svn library. You'd have to ask for this on
> >> the Subversion mailing list.
>
> > I figure since you have the browser code, and the SVN repo doesn't, it
> > would be
> > easier for you to graft a prototype into the TortoiseProc command
> > handlers in
> > a block like:
>
> > if repo-dir-from-dialog-or-admin-dir-exists && depth <> full {
> > if query-repo-version < 1.5 {
> > do repo-browse-logic dirs and files/files only checkout or update
> > } else {
> > keep current methods
> > }
> > }
>
> Sorry, but even though it seems that your example would work, it can't.
>
> > Where it would go in SVN more problematic: libsvn, wc, ra, or the svn app;
> > all or some of these needing modifying, or more? If you got the change
> > working in
> > TSVN it would make it easier to decide how best to retrofit it into the
> > command-line clients, I'd think. Bass-ackwards, I agree, but can consider
> > it a temporary proof-of-concept kludge than the actual permanent
> > implementation.
>
> Something like this has to be done in the svn library.
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> signature.asc
> < 1KViewDownload

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-11-21 07:03:50 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.