the-moog wrote:
> There is a very simple reason I can't come up with a more concrete
> answer to some of his arguments, and that is
> that I am no Windows programmer. I can't argue with Stefan on a
> technical level, though I am still sure that what I suggest is not
> outrightly impossible.
> So, in that, I did expect a more constructive response than "We won't
> do it" but perhaps this is more due to a constraint of language and
> time.
I think I've mentioned several reasons on *why* we won't do it. So you
telling that we just say "we won't do it" is unfair and also not true.
> Don't get me wrong, in my field (and I am highly respected in that
> field), I am a *huge* advocate of TSVN. Indeed indebted to the TSVN
> developers (indeed Stefan) for creating
> such a useful tool.
>
> I (and of you care to look 1000's of thers) use TSVN for controlling
> hardware design, and although we still use SVN for controlling program
> source we also
> often have slightly different requirement, e.g. for some files,
> merging is more then often meaningless, so a way to prevent users from
> selecting merge on certain file types could ne a useful contextual
> change.
FYI: I've studied electrical engineering at the Federal Institute of
Technology (http://www.ee.ethz.ch) and worked for seven years designing
analog and digital hardware. So I know those "slightly different
requirements" very well.
If you want prevent users from merging certain file types, implement
hook scripts. You can find enough documentation about how to implement
and use hook scripts in the Subversion book (http://svnbook.red-bean.com/).
> Nonetheless our requirements still probably make up (and there is no
> way of telling this for sure) a small percentage of the SVN userbase,
> so having a basic means of adapting TSVN would take its use to another
> level.
>
> I simply wanted to find if others who are not using TSVN in ways
> probably unpredicted by its developers and largest percentage of its
> userbase
> also had the same thoughts on adding non-core functionality. As such,
> my intention was only to gauge if my ideas, which I believe were
> clear, concise and very open to practical suggestion, could be of use
> to others.
> I did not intend to get into an argument on Windows internals, but I
> did want to start a discussion amongst the developers on feasability
> and limitations of any possible implementation.
From your description earlier in this thread I get that you need some
special handling for your custom setup you have in your company. And
since as you said above you're "no Windows programmer" you now hope that
we will do this for you or at least do the hard work for you. But that
simply won't work. If you need customization for your custom setup, you
should consider hiring someone to do that for you. Yes, you'd have to
pay for it, but open source doesn't mean that you get everything for
free, only that you get the source and the existing app for free. And
you're free to do with the source what you need and want. But you won't
get free customizations or free custom support.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-09-12 16:23:43 CEST