Alexander Klenin wrote:
> On 9/29/06, Stefan Küng <email@example.com> wrote:
>> If the IDE requires files to work but then changes them every time you
>> simply open a project, then that IDE is flawed (sorry, but that's
>> true). I know I also have to deal with such IDE's in my office. But I
>> always write a bug report to the company responsible for the IDE, and
>> until now I always got an answer back that I'm right and that they
>> will fix it in a later release.
> Would you please write bug report to Borland then? ;-)
That's your job. It would really help if more people would complain with
the big companies and not just expect the 'little people' working on
open source projects to write workarounds. Just try! You might be
surprised: some of the 'big' companies do listen to their customers.
> The problem is not limited to IDE config files, but to other configs
> as well. It is often hard to separate config settings into "mutable by
> developer" and "common for all developers", so usually such configs
> contain some developer-specific changes which should not be committed.
> But sometimes where are changes, like addition of a new settings,
> which must be propagated (and merged with local changes).
> This schema works very well for us except the constant annoyance of
> unchecking configs.
Use this text as a template for the mail you should write to Borland.
> Hm. However, it will still be better then current state, when I, like
> original poster, have to (almost) always de-select these files
> manually. Besides, folder rename/deletion is very rare operation.
And because it's a rare operation, it will 'fail' the first time you try
it, and then you won't remember my explanation why it will fail in your
situation and you will come here with a mail which has a big, big
"[BUG]" in the subject line. Then other people will agree with you that
this is a bug which I have to fix. I will then try to explain for the x
time that I can't fix it but it's by (Subversion) design. The discussion
will still go on, with people suggesting work arounds after work around
- with every workaround being more complicated than the other and which
none of them works reliably in all cases. I maybe would finally give in
(I hate such threads which come back every few days) and write such a
workaround. But then people will start using it, and by doing so hit
those cases where the workaround doesn't work and which I would have
mentioned before in the discussions about the workarounds.
And then? Shall I just reply with "I told you so"?
If you really want such a feature, ask for it on the Subversion mailing
list. E.g. a new property 'svn:ignoreversioned' which would exclude the
file from getting committed unless it is specified directly for commit.
Because: the Subversion library is the *only* place where such a feature
can be implemented reliably. In TSVN it would always be a hack to work
around what's not there. And it can never work reliably.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Oct 1 10:08:25 2006