M. Z. wrote:
>
> 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.
We have to use the same names for commands as Subversion does, otherwise
a lot more people get confused.
>>> 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.
If you search the subversion dev mailing list you will discover that
Subversion won't implement a 'get version number of server' function
ever, and there's a reason for that. Just read the mails from the list
there and you'll understand why (would take too long to explain
everything here again).
>
>> 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.
As I said, please don't take this the wrong way. I appreciate you
willing to do something, but that won't help much with such a feature.
This is something that requires a *lot* of testing and also requires the
dev to stay on the list and fix anything that comes up because of this.
> 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.
A port to mingw is simply not possible. Unless you like to rewrite the
whole c runtime library to incorporate all the latest features
(including tr1). mingw doesn't support that.
Also, I said this before: you might think that this could be easily
implemented in TSVN, but that simply won't work. And it wouldn't even
work if it was implemented in the svn library (the subversion devs would
have done so already, believe me). It would work in most cases, but
you're missing all the edge cases (mixed rev wc's, switched files, ...).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-11-21 22:05:49 CET