Labels are support, just copy/branch and there it is.
You just don't need locking, it's very annoying to find that someone has
locked a file that you wanted to edit. There's no need for that when you're
editing something in the top, and the other in the bottom. When a conflict
occurs, it's easy to resolve.
I do agree that there's some work to be done in the externals property
Sander
-----Original Message-----
From: Chris Estes [mailto:cestes@nexussystems.com]
Sent: vrijdag 2 april 2004 15:46
To: users@subversion.tigris.org
Subject: RE: Roadmap for 1.1
I work for a shop that is using PVCS Version Manager and the entire
development team refuses to switch from our expensive system to Subversion
without locking. Labels are an integral part of our build system. I have my
team lead asking me when Subversion will have locking, and I have developers
griping about PVCS, but I can't switch them to PVCS until the features Mr.
Nicholls lists are in Subversion. We are drifting towards other solutions
(VSS, mainly) and I'm trying to hold back the tide. A definite roadmap that
includes locking and labels would be a great help in actually TURNING that
tide.
Chris Estes
Configuration Manager
Nexus Systems, Inc.
-----Original Message-----
From: Walter Nicholls [mailto:walter.nicholls@cornerstone.co.nz]
Sent: Thursday, April 01, 2004 4:15 PM
To: users@subversion.tigris.org
Cc: kfogel@collab.net
Subject: RE: Roadmap for 1.1
I trying to prioritise features for 1.1, how about looking at the subversion
development process from the point of view of not adding
*features* but adding *users*
For example:
Subversion 1.0 - woo existing CVS users
Subversion 1.1 - woo existing SourceSafe users .. etc ..
From my point of view, I'd rather have a Subversion 1.1 sooner (eg 6
months) that has fewer features but addresses a specific user group
completely, than a Svn 1.1 later (eg 18 months)that has lots of features but
*still* doesn't enable people to migrate to it. Obviously as a SourceSafe
user (and despiser) I would like that user group to include me, but actually
I think there are some good reasons for targetting them anyway.
I haven't included "users new to source control" above because they can come
in at any time. Examples of other user groups to consider (post
1.1) might be arch users, clearcase, people who demand the repository is
stored in a SQL database ... I don't think anyone considers any of those to
be on the critical hit list.
Now my examples are pretty arbitary, but my point is that if you only
scratch some of everyone's itches, noone will be satisfied. Obviously I am
majorly biased (see www.sourcecross.org) but apart from doing everyone a
favour from making sourcesafe unnecessary, being a viable alternative to
sourcesafe will attract a large community, especially Windows users who are
a very large body of people. (I could also spin that a little and suggest
(very <tic>) that Windows users are primarily immature development shops
that may mature in future and buy SourceCast <g,d&r from all those mature
Windows developers out there, me
included!>)
Perhaps more to the point, SourceSafe users are going to be in a mind to
switch. Clearcase users probably aren't (unless they have changed jobs and
want to set up a similar system without the licence fees), and I don't think
I need to say anything about Arch devotees on this list...
Anyway to get to the point.
I think the main SourceSafe features that Subversion 1.0 does not cover
are:
1. Locking (both exclusive and advisory) 2. Shared files (same file in
two repository locations) 3. Labels (named revisions)
There are some others which I don't think are that big a deal or the
workarounds are near trivial: cloaked projects, shadow folders (use
post-commit hook), access rights (mod_svn_authz does me fine)
1. Locking
Well, you're dealing with that. Note that the lockingplan.txt when I read
seemed to focus on Exclusive locks only - we need shared/advisory locks as
well (and locks must have the user recorded against them or the advice is
not so useful)
2. Shared files
This itch is *almost* satisfied by svn:externals, but not quite. I don't
think it would be difficult to make svn:externals work safisfactorily - just
need commits to go to the right place in the right repository.
As far as shared files vs shared directories, I actually prefer the
directory anyway.
3. Labels
This isn't a big deal for me, and I think placing a label property on the
revision is perfectly adequate. (Other people may have other ideas, wanting
to say "svn co -r SUBVERSION_1_1_0_beta1" perhaps.)
----------
Of the other features
* I18n is very important, if scary (Obviously the current users all have no
trouble with English, so the support can all be channelled through English
speaking channels - ie users@ mailing list)
* The release procedures do need tightening: we don't need things like the
1.0.0 broken python on Windows, and the delay in getting Windows
1.0.1 out wasn't good either.
* Working towards anything that improves integrity of historical
information (I think I mean "renames"!)
* Work towards anything that makes it easier to resolve branching / merging
("history-sensitive merges?")
I don't have voting rights, so this is best I can do to influence people...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 2 16:03:43 2004