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

Re: [scmbug-users] Incremental builds - links from TortoiseSVN to Mantis

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2006-11-20 17:41:07 CET

jop@hot.pl wrote:

>> As I already said: it's not perfect. But it's the best we can do right
>> now, as long as Subversion doesn't provide the means we need to make it
>> better.
>>
>> And I really don't understand your problem here:
>> Why do you need to check out every directory, *then* every
>> subdirectory?? You already have a working copy - just apply the
>> properties there and commit.
>> If you then start working on a new branch, you have to check out a
>> working copy anyway - so just apply the properties then.
>
> And what if I add some directories later with for. ex tools that can be
> checked-out separately?
> Why do a project branch creator have to remember doing it each time?
> Don't you agree that one of the features of a good system is that user do
> not have to repeat actions that can and therefore should be automatic?

Yes, I agree that *it is not perfect* (don't know how many times I have
to repeat that here). It's _the best we can do_ right now.

>>> I can imagine situation in near future - The ideal situation -
>>> Inherited properties implemented in subversion and we can set it the
>>>
>>> root of repository without checking out it. Do you have any real life
>>>
>>> work around for now?
>> Yes, the way we do it now. That's our work around for this missing
>> feature.
> So could you please show me the script that can do it without forcing user
> to do it manually?

We don't have a script. The workaround I mentioned is to use the properties.

> To be honest I do not understand the amount of fuss here. I may understand
> some reason why subversion guys blocked adding properties remotely. I
> understand why you use properties for linking – flexibility etc.
> I’m not the gluer, subversion or matis developer – I’m just the person
> trying to put it together. So please take it from me I’m unbiased toward
> any of these solutions & layers exept the functionality – I like
> TortoiseSVN but also I have to admit that this particularly feature… sucks
> like the hell and today it is as good as gone or non-present – ask people
> who used it in >real-life< project with many branches – I know that if I
> allowed it in a new system it would be messy / forgotten in 6 months from
> now.

Ok then. If the feature sucks that much, then *don't use it*! Seriously:
I told and explained now several times why we did it that way, what we
need to make it better and why we can't do anything about it. But still
you keep complaining here. If you really want to complain, go to the
Subversion mailing list and ask for the 'inherited properties' or
'per-repository config file' feature. It won't help if you keep
complaining here.

> The solution would be very simple – let the user to set these values in
> TurtoiseSVN, then these can be overwritten if properties are found as it is
> today. You know better solution? Go ahead - I will be happy as a user. Do
> whatever - but not leave the present FUBAR in that narrow topic.

Thanks for the "FUBAR" - do me a favour please: deinstall TortoiseSVN
from all your computers and stop using it. Then go and buy a commercial
solution for which you pay thousands of dollars. *Then* you can keep
complaining to them if you like.
I'm tired of explaining. So I won't respond to any mails referring to
this topic anymore.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Nov 20 17:42:15 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.