On Nov 21, 4:21 am, Stefan Küng <tortoise..._at_gmail.com> wrote:
> No, because that directory is already versioned so using that directory
> as a default would be useless and wrong.
>
> > 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.
>
> I mentioned this before: to fill a sparse checkout, you must use update,
> not checkout.
> Again: you must use 'update', not 'checkout' to fill a sparse checkout.
>
> If you use checkout, you won't get a sparse wc but a nested wc. Those
> are completely different.
>
So you see it as a feature, not a bug... I find it confusing. I'll get
over it.
> > As to the research, except for not finding yet the method needed for
> > QueryRepoVersion,
>
> There is no such method/function because that's not implemented in
> Subversion - the server *never* returns a version, only capabilities.
>
So you agree. Perhaps filing a report that the libs are missing a flag
specifically for 'HandlesDepthedQueries' in the capabilities reporting
is in order to the SVN lists. It would have a similar functional
effect,
for this particular case. Probably have to wait until 1.6+, though,
even then.
> Also, don't take this the wrong way but I don't accept patches that
> haven't been tested or were not even compiled.
>
> Stefan
>
That's fine, as I can understand not wanting to risk bad code getting
in,
but at least I'm willing to put something together that has a chance
of
compiling, not just gripe about it, and I doubt somebody wanting to
incorporate prank or malicious code via a patch would bother to warn
you extra care might be needed. The lease costs of the full V$ tool
chain don't make sense for my budget or other projects, though. If
TSVN compiled with MinGW I'd be happy to do the testing, but it
doesn't, so this saves me that trouble also.
However, even if just a kludge based on the current reporting, I
still
think it's a desirable feature to incorporate, whoever does it and
however it gets done. For me it's not that high a priority, but I
like
T/SVN enough that I like seeing how it's evolving too, and I'm
willing
to put some effort in that not just me benefits. If it was, I could do
a
full mingwPORT for just my own use and use that as a private fork,
incorporating the changes into patches applied that way. That way
only I suffer for any mistakes I may make. While I did note Tigris is
doing the site update soon, there are a lot of sites that haven't,
and
due to their repository sizes and usage frequency I doubt they'll take
the time out soon to stop the servers long enough to risk doing an
upgrade. I've seen apache can get a couple commits just in the time
it
takes to update ext\apr, and at least one site still happy enough
using
svn 1.2, as the web browser view reports, for example, so I think a
lot
besides me could use it.
I'll leave it at that, thanks for listening. No reply necessary as I
have to
get back to my other stuff anyways.
Mark
---------------------------------------------------------------------
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 19:14:12 CET