[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Subversion Vision and Roadmap Proposal

From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Fri, 9 Apr 2010 14:35:19 +0100


> 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



> COMMUNITY
>
>
> But communication alone isn't enough. We need to find ways to grow our
> developer community itself. Attendance at the recent Subversion Corporation
> Annual Members Meeting was low (by design and recommendation, of course),
> but a startling realization was made there. When the agenda item for voting
> new full committers into membership was on the table, there were no
> candidates. Think about that: no new full committers for Subversion in the
> past year. This is a bad thing. We need to find a way to embrace and
> empower would-be Subversion contributors.
>

> SUMMARY
>
> I've covered a lot of ground here, but decisions in this community have
> always been and will be made on this mailing list, and they deserve to be
> made with as much information as possible. You now know where a small
> contingent of developers stand on these issues. I'd like to publicize on
> our project website a *community-endorsed* vision and roadmap ASAP, and then
> get to the business of moving Subversion forward along those lines.
>
> So what say you?
>

Well, I (as an outsider to the svn dev community) say great!

My thoughts on this: firstly, to attract more people to the community, you need to go where they are. This dev mailing list is all well and good for subversion developers, but that's exactly the audience you've already got. I think this roadmap/vision/invitation needs to be posted elsewhere, even if watered down. If you want suggestions for things to add to the roadmap then post to stackoverflow.com and serverfault.com and see what the people there come up with (I'll happily create such posts if you want me to)


I think other main issues are:
        Repo-dictated configuration (worth saying again, this is more important than you think)
        General performance, especially with lots and lots of files (I need to work with 20,000 for one project - it doesn’t work, I have to commit individual directories instead. The failure when trying looked really bad when my boss watched it once. If I was a manager and saw that, I wouldn’t allow subversion to be used for my team).
        Baselining (branches everywhere doesn't really meet many corporate requirements as we have a lot of projects in our repos, while I love the visibility of branching in svn compared to many lesser SCMs, there is still a problem with managing multiple branches - it's too easy to create a huge 'directory structure' of branches. If you have 300 projects in your repo, you can see how it quickly gets out of hand. This is probably why there's so much heat in past discussions of tagging),
        Searching in the repo - it's not that we need a new FS backend, but an index on that. After all, the repo files don’t often get touched unless you want to see old versions but the history associated with them does. So really, the revprops need a different format. That'd probably be sufficient for a perf boost for most tasks.


To get new developers, I think the first thing that needs to be done is to make entry easier. That means providing a setup ready-to-debug for people. The initial hurdle on any software project is getting set up (I find) so if you could release a VM image with everything set, or a visual studio project with the code and dependencies in there ready for someone to press 'compile', then you've made a massive headway to helping new devs get going. A pre-built Windows solution would be the ideal - if anyone has one already... let us know :) The documentation could be better (as always :) ), but getting the code running in a debugger is probably documentation enough, especially for a new developer who wants to modify things.

Good news on this email though, I love subversion and just look forward to making it better.

Andy

Received on 2010-04-09 15:35:48 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.