On 4/23/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> The shell extension doesn't show any dialogs. All the dialogs are part
> of the 'TortoiseProc' executable which is separate from the shell
> extension. We keep the shell extension as small as possible to reduce
> the chances of bugs in there. Every program has bugs, but they're more
> severe in the shell extension because that can bring down the whole
> desktop - if a crash happens in TortoiseProc, only that process goes
> down and not the whole desktop.
> And I'd like to keep it that way.
Ah, I didn't realize that was how it was structured. Of course it
makes sense not to put all that in the Shell Extension since it
doesn't need to be there.
> The "if you build it, they will come" isn't necessarily true. It depends
> on how far existing projects already are. As for example TortoiseCVS, I
> don't think they would use that framework at all. They already have a
> working solution, why should they change it and risk introducing new bugs?
TortoiseCVS is difficult example because they already have a working
product. As I mentioned, I think it would be best if they would be
part of the team working on the "TortoiseVC Core". I realize that
this probably would be a hard sell because there already is a nice
solid solution (as it also the case with TSVN) - it seems to me that
the benefits are mostly to be had in terms of consolidation of effort
and reduction of duplication of work by both communities. The biggest
advantage is going to be for new projects (and, of course, the end
users). I really have no idea if they would be at all interested in
such an endeavor.
> > A lot of what is desirable to me about this idea is the unified
> > interface. Sure, there are going to be differences and features that
> > aren't common, but there a few core features that each VC will have
> > (checkout, commit, diff, log, etc.). It may take some re-working of
> > the dialogs to accomplish this, but I believe that there is a lot that
> > can be generic enough for others to use.
>
> The dialogs are not part of the shell extension.
> Also, you can't create a common dialog for the different VC systems. If
> you read some of the threads on this mailing list, you'll discover a lot
> of discussions on how to change the UI to better suit Subversion. Which
> means they're very specific and optimized.
> I really don't like the idea of losing that.
Yes, I've read a lot of those mails. I do think that there can be a
common dialog operations such as checkout, commit, diff, log that
implement the very basic functions for each operation. I also
recognize that as certain common use cases become defined (as they are
for TSVN) - certain features and customized dialogs become more
useful. That is why ideally these basic dialogs would allow some
level of UI and behavior overriding from the VC implementation and the
VC should be able to completely replace the basic UI.
Of course, if each VC is simply going to replace all the core dialogs,
there isn't much point having them at all.
> >> One of the biggest problems here would be maintaining the compatibility.
> >> If the core gets changed, you'd have to test those changes with multiple
> >> different VC systems to make sure that change doesn't break anything.
> >
> > Yes, this is an important issue, but we already have a way to deal
> > with it - library versioning. VCSs could reasonably expect version
> > 1.x.x of the core not to make changes that would cause them not to
>
> Not necessarily: they all would have to be compiled with the very same
> VC-runtime. Otherwise you'll get memory leaks and errors.
> That's also why the shell itself doesn't use the c-runtime at all- they
> have implemented their own functions (identical to the ones in the
> c-runtime, but using the shells memory manager).
>
> And I don't think we could force all the VCs out there to use the same
> c-runtime lib.
Blech. Yes, that would be a somewhat unreasonable restriction to
impose. For something like a crawling cache, it'd probably be quite
difficult to implement having acceptable performance without passing
CRT structures & handles between the core and VC imp..
I really do think this is a good idea, but clearly there are a number
of complications, both technical and "political". I can see that the
fact that there isn't a huge benefit to existing projects, but would
add a fair amount of initial work, means that there isn't enough value
to motivate them to be involved.
Perhaps it would be better to work the other way around and work a
with a project that is interested in a new implementation, and take it
from there.
I really appreciate all the input that I've gotten.
-D
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Apr 25 17:59:34 2007