Stefan Küng <tortoisesvn@gmail.com> napisał(a):
> Anna / Marek Latuskiewicz wrote:
>
>> Well I'll be concise. I know that everyone praise the software he's
>> writing but IMHO we need to patch 2 loopholes that are present and any
>>
>> ideas / initiative to patch it would be more than welcome. For the God
>>
>> sake we're on the same side - trying to get something for 0$ that is
>> warth ClearCase + ClearQuest 10K$ each. Let reach some compromise or
>> make people pay Rational...
>>
>> 1) Well the whole idea of BugzID - it's an excellent idea but the
>>
>> first loophole is here:
>>
>> If you use any operation with build-in commit like copy, rename - you
>>
>> need to work around it putting the bug into comment because there is
>> no
>> window for that like in simple commit. Adding such a window would be
>> nice.
>
> That's true, yes. If you do operations in the TSVN repository browser,
> you won't see the bugzID edit box when you enter the commit message.
> But seriously: can you close an issue by simply copying/moving
> files/folders around?
Or importing? - well that I can imagine quite a lot. But that is not my
point really, one of the main reason why ClearCase + Clearquest solution is
that good is that it keeps connection between evry operation on the
repository and the bug, e v r y – so you can find a reason for any
operation on the repository. Without it, it would be like reading a log
book studded with bullet holes. Not to mention that it would render any
incremental build just impossible!!! If we are to implement integration and
incremental builds for real all of nothing policy must be in force.
>> 2) Checking out and in every directory, then every subdirectory..
>>
>> then do it again if you create any directory. don't you think this is
>>
>> over the top? Especially when you'd like to add this feature to a new
>>
>> repository so you need to check-out and in EVERY folder in EVRY branch
>>
>> to do that? I'm happy with the present implementation if you give me
>> the
>> way not to do it. I can see that binding these with properties has
>> several pros.
>
> 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?
>
>> 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?
>> You have to admit that adding this parameter to each subdirectory in
>> each trunk & branch & label is well even impossible if I have 100
>> labels
>> + 20 branches for a project that has 500MB of source code. or maybe it
>>
>> is possible - have you seen any working pre-commit/post-commit script
>>
>> with that? I'm not arguing anymore if you have such a script :)
>> Otherwise ideas how to patch it are more than welcome.
>
> Why do you need to add those to e.g. tags? Those are by definition
> immutable (i.e. should not be changed anymore). So adding those
> properties is not something you have to do.
> And you can add the properties to all the branches you have when you
> actually *work* on those branches, i.e. if you have a working copy
> checked out from there.
Yep. If I take a tag and I'd like to study of changes in that so I must add
a property but do not check it in as I cannot modify the tag... I see the
load of fun if I put it to the document code maintenance rules..
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.
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.
Best regards
Marek
---------------------------------------------------------------------
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:26:49 2006