> 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
