Hi,
On 02.04.10 17:28, C. Michael Pilato wrote:
> [..]
> VISION
>
> Subversion has no future as a DVCS tool. Let's just get that out there.
> [..]
> Someone wiser than I once said, "Where there is no vision, the people
> perish." So recognizing the benefits that Subversion already offers, and
> projecting a bit into the future what we'd like to see Subversion become, we
> offer the following vision statement for your review:
>
> Subversion exists to be universally recognized and adopted as an
> open-source, centralized version control system characterized by its
> reliability as a safe haven for valuable data; the simplicity of its
> model and usage; and its ability to support the needs of a wide variety
> of users and projects, from individuals to large-scale enterprise
> operations.
Simplicity... actually I think subversion could or should be even simpler. It
may be easy from our point of view around here but when I see how people use it,
it still seems to be too complicated. One has to draw a line at some level of
knowledge, sure, but think we could improve here.
Referring to my merging example below, It is astonishing difficult to explain
the svn:merginfo property and why you have to update after each commit. From a
user perspective (which are still programmers but don't know very much of
subversion) this is a "what the heck" issue.
The /trunk/branches/tags convention works but it happens from time to time that
people get the copy target wrong and copy folders into itself or something like
this. Would be nice if subversion could catch this.
Just an idea here, what about a convention enforcing wrapper around the svn
client api which would prevent wrong copies based on the convention
rules.(however one decides that)?
I guess there is more stuff where we could improve usability.
> [..]
> ROADMAP
>
> With that vision in mind, we identified a number of high-value improvements
> which Subversion should gain in coming releases. Then we took a casual pass
> at assigning some technical "plumbing" dependencies for each of these.
> Here's what we came up with, in the form "FEATURE: [DEPENDENCY ...]", where
> "FS-NG" = major FS backend overhaul, "WC-NG" = WC-NG, and "Ev2" = svn_editor_t:
>
> * Obliterate: FS-NG
> * Shelve/Checkpoint: WC-NG
> * Repository-dictated Configuration: WC-NG (?)
> * Rename Tracking: WC-NG, Ev2, FS-NG (?)
> * Improved Merging: WC-NG
> * Improved Tree Conflict Handling: WC-NG, Ev2, Rename Tracking
> * Enterprise Authentication Mechanisms:
> * Forward History Searching: FS-NG (?)
> * Log Message Templates: Repository-dictated Configuration
Performance
I think subversion needs to improve on performance. I know that WC-NG will
hopefully help here but I think it should be listed explicitly.
At work (Window Vista) it takes me minutes to update into, commit from or merge
into my working copies. I don't have numbers available but in our third party
folder we have boost and ACE/TAO with a lot of files which I guess is the root
cause (apart from using Windows ;-) for the slow performance.
In case of merging (mostly cherry picking from trunk to live and next release
branches, merge tracking is nice BUT svn:merginfo on the root folder kills it
again. After each merge I have to update again (ie. wait another few minutes)
before I'm able to commit again.
Working with a moderately large working copy on Windows is just pain.
Just my 2 euro-cent ;-)
>
> So what say you?
>
> -- C-Mike, for the NYC conference attendees
thanks for this write up :-)
--
Martin
Subcommander 2.0.0 Beta 5 - http://subcommander.tigris.org
a Win32/Unix/MacOSX subversion GUI client & diff/merge tool.
Received on 2010-04-05 16:14:49 CEST