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

RE: Cloning, branching, and cvs2svn

From: Steven Velez <svelez_at_alventive.com>
Date: 2001-10-05 20:24:12 CEST

How different is this difference?

My company currently uses Visual Source Safe and I'm keeping up with this
project to hopefully persuade the business people to switch to this when
it's ready.

Now, source safe handles branching much like it sounds like svn does.
Currently our repository consists basically of


Under branches we have several entries like


Under core we have our "trunk" code stream which maps to our standard
working space, but we have what we would consider several projects in this
working space.

Now I'm assuming we would end up creating the same structure in svn.
However, I would like to know why one scheme is recommended over the other.
  .-. | Steven Velez
  oo| | Software Engineer
 /`'\ | alventive
(\_;/) | 678-202-2226

-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Friday, October 05, 2001 1:51 PM
To: peter.westlake@arm.com
Cc: dev@subversion.tigris.org
Subject: Re: Cloning, branching, and cvs2svn

Ben Collins-Sussman <sussman@collab.net> writes:

> > product1 trunk products/product1
> > product1 .* branches/product1/{branch}
> >
> > .* release([0-9]+) releases/{path}/{1}
> > .* alpha alpha/{path}
> > .* beta beta/{path}
> > .* .* development/{path}/{branch}

I should point out that I believe we're going to advocate a policy of
organizing repositories by product, not by branch.

In other words, we're going to recommend that people lay out
repositories like this:


Instead of this:


It just so happens that the Subversion Repository only contains *one*
project; so we're laying it out like:


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 2006

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.