>
> Finally, rather than duplicating CVS, to make it really work well, we
> have to "trick" programmers into producing clean change sets and the
> best way to do that is with a different user interface (not a process
> manual). By "trick", I mean, "make doing the right thing the easiest
> course of action".
>
Now, I may be jumping in this a bit too late.
What you are proposing is a set of policies, or best practices that a
revision control system should enforce, not for better or worse, but
because you want to lead users of the system into what *you* think is
the proper way to handle revisioning in a distributed environment.
That's a little bit out of scope, don't you think? IMO, SVN is headed
toward what it should. Getting the specifics down comes later in two
forms:
1) Usage patterns. If it's apparent after quite a bit of usage that
certains aspects of SVN's features are being abused, and turn out to
cause more problems than they solve, obviously those aspects should
change. Maybe not as a forced issue, but something that the admin of the
system can tweak, or disable. Sort of like enforcing a commit message
to not be blank.
2) User interface. First off, I'm not sure what you mean by slighting
svn's interface as "weird" (or whatever the word was you used). You can
actually call something as simple as svn's command line client anything
but "simple"?
Now, of course (as I know first hand) your average users need a
graphical UI. The UI needs to enforce things like tracking changesets
(I like perforce's edit feature personally). It needs to handle easy
branching, and merging of long-term changes to the primary source. It
needs to interact seamlessly with issue tracking tools, and lead the
user to doing the right thing.
This isn't an issue of the tool being useful or correct though. This
is an issue of higher level UI. Forgive SVN for not having one just
yet. I like the idea of developing a UI based on the needs of the
users, who actually give feedback on the program and suggest changes.
Not in trying to guess how it should be used, or how the people who
actually use it want it to be used.
I don't want to drag this on any further than it is, but just wanted to
inject my point. In all honesty, this email may have missed your point,
but that's because your point was very apparent.
--
Debian - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 04:49:38 2002