Howto handle remote repository creation in a Multi-Repository scenario

["schönfeld / in-medias-res.com" <sc...@in-medias-res.com>]

Hi people,

we plan to move from CVS to SVN, as a lot of things in CVS just suck.

But now we stand in front of a problem. As versioning of different
projects is a big mess if you have them all in one repository, we want
to have multiple repositories, one per project. As the repository root
will be very big, we will have it on the NAS and export it via dav_svn,
cause a lot of sources said, that svn over nfs is not reliable and
according to your documentation one should avoid to use file:// links.

It is needed that all people working with our subversion are able to
create repositories at any time. And some of these users are Windows
users, so the problem is even worse. Now I am facing the fact, that
svnadmin is a local-only command. But how to create repositories from
remote?
I could imagine some ways to realize what i need, but i can't imagine
that noone has ever realized that it could be necessary to be able to
create repository from remote?

Can somebody hint me: What is the best way to realise this?

Best Regards

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

[Oliver Pajonk <ol...@gmail.com>]

2007/6/14, Ryan Schmidt <su...@ryandesign.com>:
> http://svnmanager.sourceforge.net/

I can recommend this. We successfully use it at my institute. It
essentially lessens the burden of the system administrator as people
"own" their repositoties and can do rights management themselves.

-- 
Oliver Pajonk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

[Patrick Schönfeld <sc...@just-imho.net>]

Ryan Schmidt wrote:
> I was also going to suggest that you should reconsider using a single
> repository for everything. Not only would i solve the problem of remote
> repository creation, but it would enable you to share code between
> projects, should that need ever arise. If you have every project in its
> own repository, you won't be sharing code between them -- at least, not
> preserving history.

Well, we do need to share code sometimes, but it is not important to
preserve history in those cases (cause the history of some code is not
relevant to another project).

> But since others have already made that suggestion and you've rejected
> it, I'll move on to answering your question:

Thanks.

> You mention you want to run mod_dav_svn on the NAS. This sounds like a
> rather sophisticated NAS box, then, if it can run custom Apache modules.

Well, i call it NAS for comfortability, but for real it is a "Network
Server".

> Hopefully that means you can also run other web software on the NAS box.

Yes, i could. I also considered using a webinterface.

> There is a web-based repository administration tool called SVNManager
> which may just do the trick for you. I haven't used it, but it says it
> can create and delete repositories, and more, so you should look into it:
> 
> http://svnmanager.sourceforge.net/

Thanks for the tipp. I will have a look at this.

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

[Patrick Schönfeld <sc...@just-imho.net>]

Arnauld Van Muysewinkel wrote:
> Note that there can be some inconvenient of putting all projects in
> the same repository.
> For example the revision graph function of TortoiseSVN gets slower and
> slower when the repository becomes bigger.
> 

That is another consideration I have taken. And we do need TortoiseSVN
for the windows users. Also we will have a *lot* of revisions in a short
time.

> Example: In my work place the admin took the decision to create one
> repository by team, with all the projects of a team in the same repo.
> With 1000+ revisions it took 3-4 minutes to get any revision graph.
> Last week I migrated a big project of 6000+ revisions from CVS. Now we
> have 7000+ revisions and the revision graph takes almost 15'. Not
> quite usable.

Ouch. This sounds quiet... uncomfortable. I don't think that our
developers would like to take this.

Best Regards

Patrick



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

[Talden <ta...@gmail.com>]

> Example: In my work place the admin took the decision to create one
> repository by team, with all the projects of a team in the same repo.
> With 1000+ revisions it took 3-4 minutes to get any revision graph.
> Last week I migrated a big project of 6000+ revisions from CVS. Now we
> have 7000+ revisions and the revision graph takes almost 15'. Not
> quite usable.

It is a shame that Subversion isn't able to provide revision-graph
information in a usable time-frame (surely some indexing mechanism can
reduce this).  Our repository at the time we actively move from CVS to
Subversion (we're in testing and refinement now) will have some 25k
revisions (across two projects).

We decided that we would rather do without the revision graph feature
(or at least accepted that we'll only be able to use it rarely)
however if it meant reducing the efforts of repository management
gaining traceable reuse between projects.   If nothing else, just
sharing single imports of 3rd party binaries makes enough of a saving
to make having fewer repositories more attractive.

Your project content may not of course see the same benefits but I'd
be surprised if this freedom to create doesn't in itself introduce
management overhead - what about backup procedures, hooks and access
control - if anyone can create repositories you can be sure that
unnecessary creation might occasionally need deletion as well and you
don't want to allow that to just anyone.

Though I'm not claiming that you are (as there hasn't been enough
discussion to really understand your issues with single repositories
beyond revision graphing), do try not to place significance on the
difference between any two revision numbers other than their order -
they really do work better than the fairly meaningless CVS revision
numbers per file and you don't really get any more useful information
from ensuring that all revisions pertain to a single project.

--
Talden

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

[Arnauld Van Muysewinkel <ar...@gmail.com>]

2007/6/14, Ryan Schmidt <su...@ryandesign.com>:
> On Jun 14, 2007, at 08:29, schönfeld / in-medias-res.com wrote:
> > Andy Levy wrote:
[SNIP]
> > Subversion talks about two variants of providing repositories. One per
> > project, or one for several projects. I would like to use the first
> > variant, but i anyway need a way to be flexible with this. What I am
> > asking for, is if there is a solution for my dillema, or not. I am not
> > asking for you to agree on how much significance i put into the
> > revision number.
>
> I was also going to suggest that you should reconsider using a single
> repository for everything. Not only would i solve the problem of
> remote repository creation, but it would enable you to share code
> between projects, should that need ever arise. If you have every
> project in its own repository, you won't be sharing code between them
> -- at least, not preserving history.

[SNIP]

FYI.

Note that there can be some inconvenient of putting all projects in
the same repository.
For example the revision graph function of TortoiseSVN gets slower and
slower when the repository becomes bigger.

Example: In my work place the admin took the decision to create one
repository by team, with all the projects of a team in the same repo.
With 1000+ revisions it took 3-4 minutes to get any revision graph.
Last week I migrated a big project of 6000+ revisions from CVS. Now we
have 7000+ revisions and the revision graph takes almost 15'. Not
quite usable.

-- 
Arnauld Van Muysewinkel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

[Ryan Schmidt <su...@ryandesign.com>]

On Jun 14, 2007, at 08:29, schönfeld / in-medias-res.com wrote:

> Andy Levy wrote:
>
>> It sounds like you're putting way too much significance on the  
>> revision
>> number.
>
> I don't think, that we are putting 'to much' significance on a  
> revision
> number. But that isn't the point is it?
>
> Subversion talks about two variants of providing repositories. One per
> project, or one for several projects. I would like to use the first
> variant, but i anyway need a way to be flexible with this. What I am
> asking for, is if there is a solution for my dillema, or not. I am not
> asking for you to agree on how much significance i put into the  
> revision
> number.

I was also going to suggest that you should reconsider using a single  
repository for everything. Not only would i solve the problem of  
remote repository creation, but it would enable you to share code  
between projects, should that need ever arise. If you have every  
project in its own repository, you won't be sharing code between them  
-- at least, not preserving history.

But since others have already made that suggestion and you've  
rejected it, I'll move on to answering your question:

> So can i solve my problem (having subversions advantages with several
> repositories and the possibility to create repos on the fly by the
> people authenticated to the server) or do i have to search for another
> RCS? :-(

You mention you want to run mod_dav_svn on the NAS. This sounds like  
a rather sophisticated NAS box, then, if it can run custom Apache  
modules. Hopefully that means you can also run other web software on  
the NAS box. There is a web-based repository administration tool  
called SVNManager which may just do the trick for you. I haven't used  
it, but it says it can create and delete repositories, and more, so  
you should look into it:

http://svnmanager.sourceforge.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Howto handle remote repository creation in a Multi-Repository scenario

[Erik Hemdal <er...@comprehensivepower.com>]

> -----Original Message-----
> From: Henrik Sundberg [mailto:storangen@gmail.com] 
> 
> 2007/6/14, "schönfeld / in-medias-res.com" 
> <sc...@in-medias-res.com>:
> > Subversion talks about two variants of providing 
> repositories. One per 
> > project, or one for several projects. I would like to use the first 
> > variant, but i anyway need a way to be flexible with this. 
> What I am 
> > asking for, is if there is a solution for my dillema, or not.
> 
> In my (novice) opinion, it is a matter of what you actually 
> need. E.g. if you have the structure: repos/
>   proj1/
>     branches/
>     tags/
>     trunk/
>   proj2/
>     branches/
>     tags/
>     trunk/
> 
> Is it really important to distinguish proj1 and proj2 as 
> separate repositories, or could they just be directories in 
> one repository?
> 
> /$
> 

Maybe, and yes.  It depends on what you need to do.

Subversion tracks the revision number of the repository, and it doesn't
assign "version numbers" to individual files.  You can choose to make
projects as directories in one repository. If you do, then a change to any
project will increment the revision numbers that every project sees.  This
can be confusing.

It might be important for you to account for every change to a project, that
is, something like:
Revision 100 made these changes, revision 101 made these others, and so
forth.  If all your projects are in one repository, you will have gaps in
that revision count, and your customer/manager/build engineer/auditor/etc.
might not like that.

You might also find it easier to manage and backup several smaller
repositories rather than one large one.

Hope this helps!

Erik



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

[Henrik Sundberg <st...@gmail.com>]

2007/6/14, "schönfeld / in-medias-res.com" <sc...@in-medias-res.com>:
> Subversion talks about two variants of providing repositories. One per
> project, or one for several projects. I would like to use the first
> variant, but i anyway need a way to be flexible with this. What I am
> asking for, is if there is a solution for my dillema, or not.

In my (novice) opinion, it is a matter of what you actually need.
E.g. if you have the structure:
repos/
  proj1/
    branches/
    tags/
    trunk/
  proj2/
    branches/
    tags/
    trunk/

Is it really important to distinguish proj1 and proj2 as separate
repositories, or could they just be directories in one repository?

/$

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

["schönfeld / in-medias-res.com" <sc...@in-medias-res.com>]

Andy Levy wrote:
> It sounds like you're putting way too much significance on the revision
> number.

I don't think, that we are putting 'to much' significance on a revision
number. But that isn't the point is it?

Subversion talks about two variants of providing repositories. One per
project, or one for several projects. I would like to use the first
variant, but i anyway need a way to be flexible with this. What I am
asking for, is if there is a solution for my dillema, or not. I am not
asking for you to agree on how much significance i put into the revision
number.

So can i solve my problem (having subversions advantages with several
repositories and the possibility to create repos on the fly by the
people authenticated to the server) or do i have to search for another
RCS? :-(

Best Regards

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

[Andy Levy <an...@gmail.com>]

On 6/14/07, "schönfeld / in-medias-res.com"
<sc...@in-medias-res.com> wrote:
> Martin Schröder wrote:
> > 2007/6/14, "schönfeld / in-medias-res.com" <sc...@in-medias-res.com>:
> >> It is needed that all people working with our subversion are able to
> >> create repositories at any time. And some of these
> >
> > Why? Everybody creating repos all the time is very unusual...
>
> If you think of a repository as a big storage for a lot of projects,
> then: Yes you are right. But we use a RCS to store versions of almost
> every small project in our company. Even our system configurations are
> organized in cvs modules and shall be organised in svn repositories. We
> found out that having "global" revisions is fine for one or some less
> projects, but for such a big number of projects it is very unhandy.

It sounds like you're putting way too much significance on the revision number.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

["schönfeld / in-medias-res.com" <sc...@in-medias-res.com>]

Martin Schröder wrote:
> 2007/6/14, "schönfeld / in-medias-res.com" <sc...@in-medias-res.com>:
>> It is needed that all people working with our subversion are able to
>> create repositories at any time. And some of these
> 
> Why? Everybody creating repos all the time is very unusual...

If you think of a repository as a big storage for a lot of projects,
then: Yes you are right. But we use a RCS to store versions of almost
every small project in our company. Even our system configurations are
organized in cvs modules and shall be organised in svn repositories. We
found out that having "global" revisions is fine for one or some less
projects, but for such a big number of projects it is very unhandy. And
it is very unhandy that someone who wants to install a development
system, has to ask an admin just because of such a simple thing as the
creation of a repository.

So yeah, it may be unusual, but we definitely need it.

> Best
>   Martin

Best Regards

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Howto handle remote repository creation in a Multi-Repository scenario

[Martin Schröder <ma...@oneiros.de>]

2007/6/14, "schönfeld / in-medias-res.com" <sc...@in-medias-res.com>:
> It is needed that all people working with our subversion are able to
> create repositories at any time. And some of these

Why? Everybody creating repos all the time is very unusual...

Best
   Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org