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.
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.
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.
I can only appologise if you think my later comment was a bit out of
line, perhaps it was.
j.
On Sep 11, 6:24 pm, "Werner F. Bruhin" <werner.bru..._at_free.fr> wrote:
> J,
>
> > Stefan,
>
> > If you release a piece of software into the public domain, be prepared
> > to listen to the whims of its users. If you wanted TSVN to be closed
> > of features that you don't like, then you should have made it closed
> > source.
>
> > I am sure you are clever enough to implement such an API system that
> > is bomb proof. I already stated that the interface would need to be
> > simple for this reason.
> > The third party plugin and its interface within TSVN could even be in
> > a different thread.
> > There are hundreds of other programs that allow third party programs,
> > and they don't seem to put "But what about bugs" as a showstopper, in
> > any case surely a bug report, "When I run my program TSVN crashes"
> > would get a farly short response.
>
> > I sent this to see what others think, let them have their say.
>
> I think the above is a bit out of line.
>
> Stefan had points why he would not want to see this in TSVN, as one of
> the key persons on the project I think that is his right (I would even
> say his duty with regards to us users!).
>
> If you want the support for your idea I would suggest you come up with a
> better response to Stefan's arguments.
>
> Werner
>
> P.S.
> Top posting is also not very helpful, as one quickly looses who said
> what and what was the question to the answer ;-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr..._at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-h..._at_tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-09-12 08:51:09 CEST