Hi Andreas,
++++ Andreas Schweigstill wrote on 13.04.2007 11:31 ++++
> Dear Henning!
>
> Henning Heil schrieb:
>> Ha! Yes, some information was missing: subclipse did not create a
>> real repository as we would do with svnadmin create /... etc., it
>> really only created new folders for the projects in the Berkeley DB.
>> To get rid of my testdata I simply moved that folder and created the
>> root repository again, problem solved. Missleading was the term root
>> repository, I got it from the installation mail of my provider -
>> there is nor root repository, the root repository is just one among
>> other repositories.
>
> Why do you use Berkeley DB? This can be because your provider installed
> a really old Subversion version (<=1.1). For newer versions FSFS will be
> the default database format. Your provider probably took Subversion from
> the Linux distribution which is very out-dated in many cases.
>
> Or do you have a specific reason why you need to create a BDB
> repository?
no, maybe I was wrong when I said BDB. SVN version is 1.1.3 and it fits
for my needs (at the moment), this might change later. I did not create
repositories with BDB manually and so I don't think it's actually in
use, the default was used for the creation.
>> which will for me be multiple repositories because I don't like
>> global revision numbers.
>
> But you know that you will never be able to perform operations across
> Subversion repositories, e.g. merging, copying, etc.?
yes, that's intentional.
> When I started using Subversion I also created tons (i.e. <10) distinct
> repositories, but finally I set up a new repository structure which
> consolidates all repositories into one big repository.
there are two main reasons, the most important is that I might share
some projects with other freelancers and some not, so rights management
was important to me and at my point of knowledge it was the easiest way
to have seperate confs with own passwd files which means seperate
repositories.
Last night I spent a while with
http://svnbook.red-bean.com/en/1.1/ch05s04.html#svn-ch-5-sect-6.1
and so think the above setup is the best solution for me, might not be
for you or others.
> When using Subversion you totally have to forget the meaning of a
> revision number. Nearly all repository operations increase the number,
> and the only information Rn > Rm contains is that Rn is newer than Rm.
> Nothing more.
>
> You should never rely on a specific revision number in the long term
> view ("R1234 contains the release for customer X."). For releases you
> have to copy a revision (in most cases HEAD) to a release or tags
> branch.
yep, I knew that before. But anyway I don't like the thought of mixing
up revision numbers across all my projects, even from a general
structural point of view I don't like this behaviour; it simply doesn't
seem logic to me. In addition I discussed that with a freelancer friend
and he had the direct opposite experience you had: he started with a
single repository in the beginning and it really gets on his nerves now.
When you combine this with the argument above I guess for me it was the
right way to have multiple repositories, I am not such a poweruser
anyway and will have a little number of files in the repositories; the
projects are almost completely seperate from each other. But mankind
always learns by experience and so I might change my structure later.
Anyway: thanks for sharing your thoughs, it's always good to have an
additional perspective.
Cheers,
Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 13 12:11:10 2007