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

Re: Customizing default svnserve.conf file?

From: Philippe Auphelle <pauphelle_at_wanadoo.fr>
Date: 2005-02-18 18:00:14 CET

Jean-Pierre,

> If our setup is to have 1 repository per project, how can
> people create new projects?
- By using svnadmin on the svn machine

> Do they need the admin to create the repo first?
- Yes.

We don't like it too much, but that's the way it is. /Ph.

Jean-Pierre Sevigny wrote:
>
> Reading this, i have a question:
> If our setup is to have 1 repository per project, how can people create
> new projects? Do they need the admin to create the repo first?
>
> I prefer having 1 repository per project, as it is easier to admin, if
> one repo gets corrupted, etc.
>
> JP
>
>> On Feb 18, 2005, at 8:38 AM, Philippe Auphelle wrote:
>>
>>> > CVS allows remote users to effortlessly create new repositories on the
>>> > server? That's news to me. ;-)
>>>
>>> :)
>>> Weeeeeellll... As far as we're concerned, a single repository is all
>>> it takes with CVS: TortoiseCVS allows us (users!) to create a fully
>>> independant project in the CVS repository thru its one-click "Make
>>> New Module" command.
>>
>>
>>
>> What? So all your existing CVS projects *are* in one big CVS
>> repository already! Every project lives in a separate directory of
>> the CVS repository.
>>
>> In Subversion, you'd do the exact same thing. There's no magic button
>> called "create module". All you need to do is create a new directory
>> in the repository, and declare it (through human imagination) to be a
>> new project. It's just as "fully independent" as any CVS project.
>> When you checkout a CVS 'module', you get a working copy of exactly 1
>> directory in the CVS repository. When you checkout a SVN project
>> (URL), you get exactly 1 directory in the SVN repository. There's no
>> difference here at all. In both CVS and SVN, each "project" is just a
>> directory in the repository. Very simple.
>>
>>> And even though I'm far from being a hardcore CVS specialist, no
>>> Tortoise checkout I know of will let me inadvertently get all the
>>> projects, and trunks, and branches and tags repositorywide on my
>>> local disk at once!
>>
>>
>>
>> That's because CVS stores branches is an a separate dimension, whereas
>> SVN represents branches as ordinary directories. So, "don't do
>> that". Don't checkout the project/branches/ dir, don't checkout the
>> project/tags/ dir. *Do* checkout the project/trunk/ dir.
>>
>>
>>> IOW, those are two CVS features we like because they allow us to
>>> 1) Be independant (look ma', no admin!)
>>> 2) Better protect ourselves against ourselves.
>>>
>>
>> I fail to see any difference between SVN and CVS in this regard. A
>> "project" directory in a CVS repository is just as "independent" and
>> "protected" from other projects as a "project" directory in an SVN
>> repository.
>>
>>
>>> > Well, duh... don't checkout the root of the repository. (That's
>>> > always a horrible idea, since you'd end up getting a copy of every
>>> > branch and tag!)
>>>
>>> I admit we are biased on this one:
>>> On the very first test we did after installing svn and converting a
>>> test CVS project, that's exactly what we did using TortoiseSVN (cuz
>>> it looked natural to do so at the time!). We of course got precisely
>>> the 'great' results you mention :-) ...
>>
>>
>>
>> If you guys don't read the docs and don't understand the basic
>> concepts of SVN, I can't help you. You're right, SVN isn't 100%
>> identical to CVS. If you start blindly using SVN assuming it's a
>> complete drop-in transparent replacement for CVS, you're going to get
>> burned. Read the book, learn the subtle differences, make tiny
>> adaptations. :-)
>>
>>
>>
>>>
>>> > "Inadvertent alteration"? That's why access control exists. And
>>> > besides, even if somebody accidentally commits to the wrong place, you
>>> > just undo the change. That's the whole point of version control,
>>> > right?
>>>
>>> Hmm, so far, we have only been thinking about protecting ourselves
>>> from not-so-inadvertent-alteration while trying to implement stuff.
>>> I sure like the idea of being able to create as a user new
>>> independant "containers" for my project(s) better than that of using
>>> a single source tree for (mostly) everything.
>>
>>
>>
>> Yes, these 'containers' are called directories. They live in the
>> repository. You're already doing this for your CVS projects.
>>
>>
>>> But among the non-imaginary topics, we definitly think svn makes it a
>>> bit too hard on the admin:
>>> Not having a way to spec the default fs-type falls in the same
>>> category as not being able to spec a default svnserve.conf template
>>> over the hard-coded default one: Just yet another possible cause for
>>> an administrator mistake! (in case you didn't guess, we decided to
>>> use FSFS)
>>> Not to mention the impossibility for the admin to delegate repository
>>> creation to users through the plain svn client interface, of course :-^)
>>
>>
>>
>> I think we're talking in circles now. Here's my recap of the
>> conversation:
>>
>> Q: We want users to be able to create separate repositories for their
>> projects.
>> A: Not possible.
>> Q: But CVS lets us do that!
>> A: No it doesn't.
>> Q: Sure it does, users just create a new module.
>> A: Ah, so then all your projects are in *one* big CVS repository.
>> Your users are simply creating new directories in the repository.
>> Sure, SVN can do the exact same thing. You're all set.
>> Q: But... SVN doesn't make it easy to create new repositories!
>>
>> ??
>> ...so, uh, I'm at a loss here. Maybe mail this has cleared things up.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 18 18:08:45 2005

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.