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.
> 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 agree that it isn't an easy task - that is why I'm proposing
this as a way to lower the barrier so that is more feasible.
> 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.
I really don't think that this is accurate; both monotone and
mercurial are very stable, but the purpose of this isn't really to
discuss the merits of each VC or to gauge the stability of each.
> > 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.
The disconnected working model is only part of the package; for the
corporate world, I can see how it would be a confusing concept, but
really I think it can offer benefits even there. For example, the
ability to commit at intervals without breaking the build for others
working in the same branch can encourage smaller specific commits. A
user working on a feature for 6 months without pushing their work to
the main repository is obviously not doing something right - this
would be a big problem, but the same argument could be applied to
someone using CVS or SVN vs. VSS - you don't *have* to commit your
changes. I really think that this is just a training issue.
I guess I'd like to avoid having a big discussion about the merits of
DVCS or the features / gaps of each vs. SVN or CVS or anything, but
please consider that Mozilla has adopted mercurial as a sign of
traction.
> > 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.
> > 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.
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.
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
work, but a new major release would require changes. This isn't
fool-proof, but with care, I think that this is a simple solution that
would work. There may be occasional unintended incompatibilities, but
such is life.
As I mentioned initially, I just want to gauge interest in this idea.
If there is none, so be it; I don't have the time to undertake
something like this on my own and I also don't think it is worthwhile
unless a project like TSVN would be interested to participate. With
that said, I really think that there is an opportunity now to
facilitate a unified VC experience for Windows users who need to use
several VCSs.
Thanks,
-D
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Apr 22 17:19:23 2007