Daniel Atallah wrote:
> On 4/21/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
>> Daniel Atallah wrote:
>> > I'm sure we all know about the various complications (overlays,
>> > excessive menu items, etc.) that arise when trying to use both TSVN
>>
>> What do you mean with "excessive menu items"?
>> Even if we would share our efforts between all Tortoise clients, the
>> menu items still would have to be there. Both TSVN and TCVS only show
>> the menu entries which can be used (e.g., no 'commit' entry for
>> unversioned folders).
>
> I'm thinking of the menus that appear on unversioned directories;
> there are two entries for TSVN (Checkout and the submenu) - I assume
> that TCVS has the same ones. I was thinking that these could be
> consolidated into a single "VC Checkout" and a TortoiseVC submenu, the
> specifics of which I haven't really considered in detail. The point
> being that the Shell root menu wouldn't have to grow per VC type.
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.
[snip]
>> > Obviously, the TSVN project can't be expected to maintain an
>> > all-encompassing Windows Explorer shell that supports lots of
>> > different version control mechanisms, but what about the possibility
>> > of converting TSVN to a "Core" and a "VC implementation" (i.e. the
>> > actual svn integration)?
>>
>> Nice idea. But who would do the core and who would work on the rest?
>> Implementing something like this would be enough work for a whole
>> separate project.
>> Besides that, it would require a big amount of communication between the
>> different projects, which you maybe know is far from easy. If you're
>> working in an office, you know just how hard it is to communicate with
>> the different departments. Now imagine the problems with different
>> projects, with each of them having a completely different underlying
>> system, and different requirements.
>
> I think this would be the most complicated part. Dealing with
> politics is always unnecesarily painful and complicated. You're
> right, it could be a separate project. If folks from TSVN and TCVS
> (and others too) could come together and work on it, I think that
> would be deal with 80% of the political difficulties. I have no ideas
> if this is remotely feasible, or if trying to coordiate that would
> simply be impossible.
>
> As far as other future users of the core, I think that it is a matter
> of "if you build it, they will come;" If your project depends on a
> library, you're certainly going to take an interest in directing
> changes to that library to help your own project. I'm not suggesting
> that it is a trivial task, but I really think that it is doable.
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?
> 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.
> Does the status cache really need to be SVN-specific? I'm not
> familiar with the source, but it seems like the crawling, the
> "database" and the overlay rendering should all be relatively VC
> independent - the only thing that really needs to be SVN-specific is
> the examining of files, and deciding whether or not to recurse. I
> could be way off here, but it seems like this is just a textbook
> example of having an interface that the various VCs could implement to
> provide the status info for each file.
>
>>
>> > With this setup TSVN would only need to continue to maintain the
>> > "reference" SVN VC implementation. Such a setup would significantly
>> > reduce the difficulty for other projects to implement a nice Shell
>> > Interface and would also provide a nice unified experience to the end
>> > users.
>>
>> 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.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Apr 23 22:42:09 2007