You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by we...@tigris.org on 2009/05/08 20:15:23 UTC
Request: Specifications / Requirements that only svn can meet
Folks,
I work for a government contractor that is likely to force us into using an extremely
overpriced and unnecessarily complicated version control system adored by pointy-haired managers everywhere (you probably know the one... :).
I have been asked to submit requirements for our new version control system. In an effort to delay or prevent the onset of ill-rationality I want to present requirements that can be met *ONLY* by svn.
1. Is there a prepared list of specifications / requirements that only svn can meet available somewhere?
2. If not or there are additional requirements you folks know about please mention them on the list.
My deadline for submitting this list is COB Monday, 11 May 2009. I'll be happy to wrap up the discussions here with a summery of svn only requirements so that others can benefit.
-Andrew
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2120944
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Request: Specifications / Requirements that only svn can meet
Posted by Blair Zajac <bl...@orcaware.com>.
On May 9, 2009, at 11:27 AM, Blair Zajac wrote:
> On May 8, 2009, at 1:15 PM, webpost@tigris.org wrote:
>
>> Folks,
>>
>> I work for a government contractor that is likely to force us into
>> using an extremely
>> overpriced and unnecessarily complicated version control system
>> adored by pointy-haired managers everywhere (you probably know the
>> one... :).
>>
>> I have been asked to submit requirements for our new version control
>> system. In an effort to delay or prevent the onset of ill-
>> rationality I want to present requirements that can be met *ONLY* by
>> svn.
>>
>> 1. Is there a prepared list of specifications / requirements that
>> only svn can meet available somewhere?
>>
>> 2. If not or there are additional requirements you folks know about
>> please mention them on the list.
>>
>> My deadline for submitting this list is COB Monday, 11 May 2009.
>> I'll be happy to wrap up the discussions here with a summery of svn
>> only requirements so that others can benefit.
>
> How about:
The other thing to do is to look through
http://svnbook.red-bean.com/en/1.5/index.html
and see if there's any features there the other system doesn't have.
Blair
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2149627
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Request: Specifications / Requirements that only svn can meet
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
> -----Original Message-----
> From: Blair Zajac [mailto:blair@orcaware.com]
> Sent: Saturday, May 09, 2009 7:27 PM
> To: webpost@tigris.org
> Cc: users@subversion.tigris.org
> Subject: Re: Request: Specifications / Requirements that only svn can
> meet
>
> - Support on all major platforms:
Don't forget to mention the Unixes. (eg Solaris).
Also, mention that it is becoming a standard for internet-based version
control systems, even Microsoft has adopted it as the client of choice
(ahem) for their opensource efforts at Codeplex. If MS say it's good,
there's no reason anyone else can criticise it, especially if they are
pushing for a Microsoft solution.
Also, there are plenty of integration options - eg Clearcase to SVN
connector. At least this shows that SVN is well recognised among the
alternative VCS vendors.
You might also like to read this
http://www.wandisco.com/pdf/ClearCase.pdf as it has the usual table of
differences in favour of SVN (via WanDisco's gubbins)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2186805
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Request: Specifications / Requirements that only svn can meet
Posted by Blair Zajac <bl...@orcaware.com>.
On May 8, 2009, at 1:15 PM, webpost@tigris.org wrote:
> Folks,
>
> I work for a government contractor that is likely to force us into
> using an extremely
> overpriced and unnecessarily complicated version control system
> adored by pointy-haired managers everywhere (you probably know the
> one... :).
>
> I have been asked to submit requirements for our new version control
> system. In an effort to delay or prevent the onset of ill-
> rationality I want to present requirements that can be met *ONLY* by
> svn.
>
> 1. Is there a prepared list of specifications / requirements that
> only svn can meet available somewhere?
>
> 2. If not or there are additional requirements you folks know about
> please mention them on the list.
>
> My deadline for submitting this list is COB Monday, 11 May 2009.
> I'll be happy to wrap up the discussions here with a summery of svn
> only requirements so that others can benefit.
How about:
- Has support for write-through proxies that allow you to have remote
repositories at remote offices that have a local cache for very fast
read operations. This also supports disaster recovery in that a copy
of the repository is at a very remote location.
- Supports hot backups of the repository; no down time is required.
- Supports mirroring/backup repositories that will have a copy of any
commits in the master repository within one second of a commit in the
master repository (using svnsync).
- Support on all major platforms:
Windows
Linux
Mac OS X
- Integrates into all major ticket tracking systems, i.e.
Jira
Trac
- Integrates into all major IDEs
Eclipse
NetBeans
Microsoft Visual Studio
Windows (with Tortoise)
- Very large ecosystem around it.
- No vendor lock-in. No risk that the product will go away and you'll
loose your investment in using it.
- Provides bindings so additional tools can be scripted to it in
popular languages
Java
Python
Perl
Ruby
- Provides a multi-layer abstraction where code can be written to any
of the layers in Subversion, from direct repository access using
svn.fs and svn.repos up to client access using svn.client.
- Supports constant time branching and tagging operations
- Supports disconnected operations where the client doesn't have to
talk to the server to do all operations.
- Requires a very light server infrastructure is required. Only a
single server is ever required to run a repository for a single company.
- Supports both the lock-modify-unlock and copy-modify-merge models.
- Supports pulling code in from remote repositories so a single piece
of code can be shared into multiple projects with the use of
svn:externals. For example, if you needed some source code from
Apache Ant, you could add an svn:external from your repository at http://example.com/svn/repos
to http://svn.apache.org/repos/asf/.
- Supports all the different authentication models that Apache and
svnserve support, so it's very flexible. Can use flat text files,
LDAP, ActiveDirectory, SASL, etc.
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2149568
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Request: Specifications / Requirements that only svn can meet
Posted by Les Mikesell <le...@gmail.com>.
webpost@tigris.org wrote:
> Steve,
>
> You are correct, we primarily want to avoid the Expensive Bloated Version Control System (tm).
>
> Requirements that CVS and svn (and perhaps other open source software) can meet but commercial products can not would be fine.
>
> In the meantime I'll start bringing together some information on the long term costs of using the other system. As a former site administrator of the commercial system in question I am in an especially good place to make that argument.
Be sure to include the free GUI clients/plugins (tortoise, subclipse,
etc.) as a plus for svn.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2124663
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Request: Specifications / Requirements that only svn canmeet
Posted by Les Mikesell <le...@gmail.com>.
Ted Stern wrote:
> On 08 May 2009 14:46:40 -0700, webpost@tigris.org wrote:
>> Steve,
>>
>> You are correct, we primarily want to avoid the Expensive Bloated
>> Version Control System (tm).
>>
>> Requirements that CVS and svn (and perhaps other open source
>> software) can meet but commercial products can not would be fine.
>>
>> In the meantime I'll start bringing together some information on the
>> long term costs of using the other system. As a former site
>> administrator of the commercial system in question I am in an
>> especially good place to make that argument.
>>
>> -Andrew
>
> Here are a couple of requirements I don't think "EBVCS" can handle,
> but it's possible to do it in OSS tools such as Subversion, Git,
> Mercurial, Bazaar, etc.:
>
> High security access from anywhere on the internet.
>
> You can set up a single account that is the only one that can view the
> project.
>
> Then you multiplex the account via its ~/.ssh/authorized_keys file.
>
> Documented for Subversion in
>
> http://svn.collab.net/repos/svn/trunk/notes/ssh-tricks
> (Trick #4)
>
> and
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth
>
> There are similar ssh server modes for other systems.
>
> This lets you access the code from anywhere with an ssh route to the
> host.
>
> I need svn+ssh access this way because
>
> 1) Third party source code license requirements require secure access.
> 2) Users/developers are nationwide and don't have local accounts.
> 3) It works from any OS that OpenSSH runs on :-).
>
> plus this bit of sugar:
>
> 4) With svnserve's --tunnel-user option, you can change the log into a
> human-readable name format. This is a welcome change from CVS
> because our login names are basically line noise. The name I
> convert to is the standard name email format, first.last
> (@company.com is assumed).
Or, use https with an apache configuration that requires a client
certificate.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2154567
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Request: Specifications / Requirements that only svn canmeet
Posted by Ted Stern <do...@gmail.com>.
On 08 May 2009 14:46:40 -0700, webpost@tigris.org wrote:
>
> Steve,
>
> You are correct, we primarily want to avoid the Expensive Bloated
> Version Control System (tm).
>
> Requirements that CVS and svn (and perhaps other open source
> software) can meet but commercial products can not would be fine.
>
> In the meantime I'll start bringing together some information on the
> long term costs of using the other system. As a former site
> administrator of the commercial system in question I am in an
> especially good place to make that argument.
>
> -Andrew
Here are a couple of requirements I don't think "EBVCS" can handle,
but it's possible to do it in OSS tools such as Subversion, Git,
Mercurial, Bazaar, etc.:
High security access from anywhere on the internet.
You can set up a single account that is the only one that can view the
project.
Then you multiplex the account via its ~/.ssh/authorized_keys file.
Documented for Subversion in
http://svn.collab.net/repos/svn/trunk/notes/ssh-tricks
(Trick #4)
and
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth
There are similar ssh server modes for other systems.
This lets you access the code from anywhere with an ssh route to the
host.
I need svn+ssh access this way because
1) Third party source code license requirements require secure access.
2) Users/developers are nationwide and don't have local accounts.
3) It works from any OS that OpenSSH runs on :-).
plus this bit of sugar:
4) With svnserve's --tunnel-user option, you can change the log into a
human-readable name format. This is a welcome change from CVS
because our login names are basically line noise. The name I
convert to is the standard name email format, first.last
(@company.com is assumed).
Ted
--
Frango ut patefaciam -- I break so that I may reveal
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2125290
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Re: Request: Specifications / Requirements that only svn can
meet
Posted by we...@tigris.org.
Steve,
You are correct, we primarily want to avoid the Expensive Bloated Version Control System (tm).
Requirements that CVS and svn (and perhaps other open source software) can meet but commercial products can not would be fine.
In the meantime I'll start bringing together some information on the long term costs of using the other system. As a former site administrator of the commercial system in question I am in an especially good place to make that argument.
-Andrew
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2123059
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Request: Specifications / Requirements that only svn can meet
Posted by Steve Bakke <st...@amd.com>.
On May 8, 2009, at 4:15 PM, webpost@tigris.org wrote:
> Folks,
>
> I work for a government contractor that is likely to force us into
> using an extremely
> overpriced and unnecessarily complicated version control system
> adored by pointy-haired managers everywhere (you probably know the
> one... :).
>
> I have been asked to submit requirements for our new version control
> system. In an effort to delay or prevent the onset of ill-
> rationality I want to present requirements that can be met *ONLY* by
> svn.
>
> 1. Is there a prepared list of specifications / requirements that
> only svn can meet available somewhere?
>
> 2. If not or there are additional requirements you folks know about
> please mention them on the list.
>
> My deadline for submitting this list is COB Monday, 11 May 2009.
> I'll be happy to wrap up the discussions here with a summery of svn
> only requirements so that others can benefit.
>
> -Andrew
How about at least setting the requirements such that a number of open-
source tools would do? I seriously doubt that Subversion has
something so unique and vital that you can't find with other open
source version control systems. Seems to me that looking at the setup
costs would be a good thing. That's not to say that Subversion
wouldn't do the job. You mainly want to convince them not to use the
expensive bloated solution right?
-steve
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2122357
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Request: Specifications / Requirements that only svn can meet
Posted by Stefan Sperling <st...@elego.de>.
On Fri, May 08, 2009 at 01:15:23PM -0700, webpost@tigris.org wrote:
> Folks,
>
> I work for a government contractor that is likely to force us into using an extremely
> overpriced and unnecessarily complicated version control system adored by pointy-haired managers everywhere (you probably know the one... :).
Hmmm... I think your case is clear to me ;)
> I have been asked to submit requirements for our new version control
> system. In an effort to delay or prevent the onset of ill-rationality
> I want to present requirements that can be met *ONLY* by svn.
It is open source. Using the software is free of charge. You don't
depend on a single vendor to provide support, so there is no vendor
lock-in when it comes to support.
If Subversion does not fulfill your requirements you can improve it.
The community is run very professionally. Have you already noted the
refreshing lack of flame wars on our lists? The developer community
is very open for constructive contributions from users, so getting things
into the code base that your organisation really needs is very much
possible if you communicate well with the community and contribute
in a constructive and co-operative manner.
With enough skill and patience, you can even grow your own in-house
committers that co-maintain Subversion for you together with the rest
of the community. The place where I work has done that. And you are
encouraged to do this as well when using Subversion in your organisation,
without having to commit to any formal agreements. The only thing that's
required is maintaining a healthy relationship to the community.
By definition, a proprietary vendor cannot provide this.
Stefan