You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Sams Niko <ns...@vivid-planet.com> on 2004/12/01 07:49:31 UTC
another repository layout
Currently I have a CVS Repository with about 20 projects. Some of them
are very small (only 10 files) - but 5 of them are quite big (500 MB+).
The Projects don't depend on each other.
In CVS i have allready some thousand commits.
When i now convert it into ONE svn-repository with that structure:
/trunk/project1
/trunk/project2
/trunk/project3
/brances...
/tags...
I get as a result really high and confusing revision-numbers!
Do you think it is quite normal to have revision-numbers like 10000?
Also imho it is not nice if the revision-numbers of the small projects
change all the time - although nothing is done in here...
So the solution would be a repository for each project?
Multiple Repositories olthough would be a hard part:
1. TSVN users should be able to create new projects
2. Can users see using TSVN in http://server/ all avaliable projects
in the repo-browser?
3. the config-files have to be rewritten for every repoistory - right?
Another idea would be to create for the 5 big projects a repository -
and for all other small projects one single repository. This would solve
1. and 3. (more or less) - but 2. too?
tanks for any ideas and suggestions...
Niko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: another repository layout
Posted by Niko Sams <ns...@vivid-planet.com>.
Steve Greenland wrote:
>But really, you shouldn't. Revision numbers don't mean anything, any
>more than CVS file revision numbers meant anything.
>
Ok, if they don't mean aynthing it shouldn't be a problem... I hope the
developers working with the
repository don't have a problem with that :D
>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.]
>
>
I think we don't need that - we only used for one Project once a
branch... we are working only
on websites and the changes have to go online immideately...
And tags we used never...
If we should ever i can easily move the structure...
>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.
>
actually there are no other reasons...
Thanks for your help, I know now what to do :D
Niko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: another repository layout
Posted by Steve Greenland <st...@lsli.com>.
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