I'd be glad to give you a wish list.
1. Clearer error messaging when things happen like trying to merge a
non existent revision of a file. The current messaging isn't clear and
people get confused.
2. Repeated Merging Support - We currently use branching per activity,
and also "per release". We use our trunk as the "development", or
"unstable" branch, and then when we are ready to go to QA, we branch and
continue development on the release branch until production (this is the
same model you guys use I think). Once a build goes to production this
branch becomes our production support branch. Given this model,
repeated merging is a big deal for us as our merging from the "release
branch" is still done en masse rather than "per change". I plan on
changing this part of our model at some time in the future, however this
will be a big deal for people as we try to evangelize Subversion outside
of my group.
3. File Locking - We have one documentation CVS repository containing
Word documents and diagrams that we have not converted because of the
lack of locking support. Once we have locking we will be a 100%
Subversion shop. In addition, we have certain artifacts that we
publish per build that we currently publish by having a samba share to a
directory on our internal web servers. The ideal situation for this
scenario would be to set up a "web folder" so that our users could
upload files and they would be versioned "invisibly". Currently we
have no version control for these artifacts, and I do not want to teach
my business users to use source control. Full WebDAV autoversioning
would be huge win for us in this scenario. My understanding from
reading the book is that locking support is one of the reasons this
doesn't work.
4. Repository Replication - The svnadmin dump --incremental was a good
step towards this, and this is what I am using to replicate one of our
external repositories to our internal systems, however, I would love to
see real time replication. One of the things we are looking at is to
use SVN in some capacity for content management. With this goal
(actually, just sourcing your code falls under this category), failover
is very important, hence replication is a "must have". If we could
have a relational backend it would be that much better.
5. I'm not sure what this would be called, but it would be very useful
for us to be able to query a list of files/revisions that have a
property set to a certain value. For example, "give me all files where
prop:defectnumber is 100". I know this type of functionality was
discussed briefly in relation to tagging but I would use it in a
completely different way so this implementation would have to be
general.
6. More detailed API documentation. Currently I do not have the time
(nor does my staff) to dig around the code or current API docs. In
addition to using CruiseControl, we have wrapped our build process with
a lot of automation to enfoce the process. Most of this is now using
Python and the SVN command line, however we have a lot of Java code
running in Tomcat to help us administer the source base. A chapter in
the book with detailed documentation on using the SVN API would be great
(something like a cookbook with common things you would do to copy, co,
access properties, etc from C / Python / Java, etc).
7. Finally, more efficient workarea metadata management. Currently
under operating systems like Solaris, checkout times are very slow due
to the amount of small files that are copied / created / updated during
the checkout or update process (and the number of stat calls that are
performed). We currently have to use asynchronous file I/O under
these environments (for workareas, NOT THE REPOSITORY) with a very
aggressive backup strategy to ensure performance for the teams in this
environment. Figuring out a way to optimize this aspect of the product
would be a big win.
I hope this helps. Once again, thanks for a great product.
-- Ron
On Fri, 2004-07-23 at 09:56, C. Michael Pilato wrote:
> Ron Bieber <ron@bieberlabs.com> writes:
>
> > As a manager, converting to Subversion was one of the best decisions I
> > have made thus far that had a such a direct and highly visible impact on
> > the productivity of my team.
> >
> > I hope this helps you make your case for Subversion. My personal
> > opinion is that no one should even consider CVS at this point in time.
> > Subversion is a great product and the support you get just on the
> > mailing lists alone (from the development team no less!) is second to
> > none.
>
> Wow. I think I might cry. That was not only a pleasant read, but it
> was quite encouraging.
>
> So -- because, as a developer of Subversion, I want to know -- could
> you list your top few complaints/wishlist items for Subversion?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
Received on Sat Jul 24 15:22:28 2004