Daniel Atallah wrote:
> I've had a crazy thought, and figured I'd get a gauge on interest from
> you guys.
>
> I've been using TortoiseSVN for several years, and used TortoiseCVS
> for a couple years prior to that. I really love the interface and the
> easy with which it allows people to easily adopt better revision
> control practices.
>
> 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).
> and TCVS at the same time - this will be further complicated as other
> VCs construct similar UIs (I know there has been some discussion of
> this for both monotone and mercurial, and I wouldn't be surprised to
> hear of others).
Shell extensions are not easy to implement. I seriously doubt that
monotone or mercurial will create such a client: the userbase is not big
enough for someone to get really motivated to start working (and
learning) on this. Yes, I've seen such posts too from users discussing
that they want/need something like a Tortoise client. But the reason
they want that is always to attract more users. IMHO a good client is
only half (or even less) about what's needed to attract new users. The
biggest part is to have a good and stable version control system. And
from what I've seen (and tried) in monotone and mercurial, they're way
behind Subversion.
> As distributed VCs become more popular, we're going to see a larger
> variety of systems in common use, so I think that it is worth thinking
> about ways to make life easier for people who need to use several VCs.
My opinion:
Distributed VCs won't become as popular as e.g. Subversion. They're
great for certain setups where you're away from a connection to the
central repository. But those situations are not that common, and get
less common now that you can get a fast internet connection via your
cell phone (Natels as we call them here in Switzerland :) ).
Distributed VCs have one big disadvantage: you don't have a central
place where the latest/greatest version is stored. Users can work
'privately' almost indefinitely. Now go and tell that your IT department
and your boss. They will be shocked: no central place for their valuable
data? Who does the backup? What happens if a users computer looses all
data and that user has been working on a feature for e.g. 6 months
without pushing it to someone else?
Yes, you can dictate that users push their changes to some special
repository from time to time, but that's the same as dictating VSS users
to always check in their changes before they leave - it just doesn't
work. With Subversion and other similar VCs users will soon discover
that if they don't commit often, they have a hell of a work to do later
with merging.
> 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.
> My thought, at a very high level is that the "Core" could implement
> the various Shell/Explorer hooks and the Cache, along with other
> unified UI screens like the commit dialog, etc. VC implementations
> would implement a set of Interfaces which could either tie into
> existing UI screens / Cache implementation, or replace even
> potentially override them.
The shell itself provides such hooks. Sure, we could implement some
layer above the bare shell hooks which would provide some more
functionality for VC systems. But since those systems are really
completely different, there's not much we would gain.
And the status cache of TSVN is specific to Subversion. It wouldn't work
for e.g. CVS or other systems. And I don't think that we could change it
in a way it could work for other systems too.
The only thing we could maybe gain would be more free overlay slots. But
that's all.
> 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.
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 Sat Apr 21 16:47:01 2007