> 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.
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!
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.
> 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 :-) ...
> "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.
> I think you're inventing imaginary problems here. :-)
There is always some truth to that, specially since we're considering
moving from the devil we know to the one we don't! The problem is
figuring out what's imaginary (or rather due to ignorance, in this case)
from what is not. You're helping me, there.
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 :-^)
We're gonna keep on testing harder (doing it the way you suggest), and
see how we feel in the end.
Thanks again!
Ben Collins-Sussman wrote:
>
> On Feb 18, 2005, at 2:55 AM, Philippe Auphelle wrote:
>
>>
>> Anyway, since that's not the way svn works, and since we are still in
>> the study phase, I guess we'll have to either do with it or stick with
>> CVS.
>
>
> CVS allows remote users to effortlessly create new repositories on the
> server? That's news to me. ;-)
>
>>
>>> Maybe a better idea is: make one big repository. Users can start new
>>> projects by creating new directories in the repository.
>>
>>
>> We considered that, but from what I know of svn (please correct me if
>> I'm wrong), we are worried by at least three aspects:
>>
>> 1) It goes against the rule of thumb (FAQ) that says "If the projects
>> are related, and are likely to share data, then it's best to create one
>> repository with several subdirectory". Here, lotsa projects are small
>> unrelated.
>
>
> Projects that live in a single repository don't *have* to share data.
> It just opens up the possibility, that's all.
>
>> 2) Any straight repository checkout will bring the whole repository
>> while just a specific project (subdir) is actually needed
>
>
> 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!)
>
> Remember that 'svn checkout' takes a URL argument. Every project would
> still have a unique URL, whether they all live in separate repositories
> or in one big repository.
>
>> 3) Separate repositories insures against inadvertent alteration of the
>> tree for project A by someone working on unrelated project B.
>>
>
> "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?
>
> I think you're inventing imaginary problems here. :-)
>
> Look at the ASF repository: http://svn.apache.org/repos/asf
>
> Dozens of projects living in one repository, happily ignoring each
> other. Once in a great while, a project gets renamed, or moved from the
> "incubator" area to a full-fledged project. No problems at all.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 18 15:40:41 2005