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

Re: another repository layout

From: Steve Greenland <steveg_at_lsli.com>
Date: 2004-12-01 20:01:58 CET

On Wed, Dec 01, 2004 at 08:49:31AM +0100, Sams Niko wrote:
> [converts many CVS projects into one big subversion repo]
>
> I get as a result really high and confusing revision-numbers!
>
> Do you think it is quite normal to have revision-numbers like 10000?

Yes.

> Also imho it is not nice if the revision-numbers of the small projects
> change all the time - although nothing is done in here...

The revision numbers aren't for projects, but for the whole repo.

> So the solution would be a repository for each project?

If you're going to obsess about revision numbers, yes.

But really, you shouldn't. Revision numbers don't mean anything, any
more than CVS file revision numbers meant anything. Well, okay, actually
Subversion revision numbers *do* mean more, since you can talk about
"Project X at revision NN", which you can't in CVS. But they're just
handles to a particular repo state; the values don't mean anything.

OTOH, I would suggest that if the projects are independent, you
might find a structure like this more useful:

ProjectA/trunk
ProjectA/branches
ProjectA/tags
ProjectB/trunk
ProjectB/branches
ProjectB/tags
[etc.]

Now, there may be other reasons to split into multiple repos, such as
different access requirements, or backup size, or purely management
issues, but I wouldn't base my decision on revision numbers at all.

-- 
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
                           -- (Stolen from the net)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 1 20:04:14 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.