You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by wimpunk <bk...@spammotel.com> on 2008/03/07 14:59:56 UTC
Repository construction
Hi,
A college has a rather strange idea on setting up his repository and I'm
wondering if it will cause any troubles for subversion since I'm the
administrator.
He's used working with SourceSafe and now he's planning to use a
directory structure looking like this:
project/major/module/minor/version
Personally I would remove major, minor and version from the structure
but he really wants it that way. When he starts a new major, he creates
the substructure again and copies the latest version to this major.
As far as I understand, there's no server-side objection doing this. For
subversion is doesn't matters where you create your branch. Is this
correct?
Will it differ at the server size concerning the size of the db if we
use a more normal construction like this:
project/module/{trunk,branches,tags}
I hope there's no problem doing his idea since it already took some time
to convince him using subversion.
Kind regards,
wimpunk.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository construction
Posted by wimpunk <wi...@gmail.com>.
Ulrich Eckhardt wrote:
> On Friday 07 March 2008, wimpunk wrote:
>> A college has a rather strange idea on setting up his repository and I'm
>> wondering if it will cause any troubles for subversion since I'm the
>> administrator.
>> He's used working with SourceSafe and now he's planning to use a
>> directory structure looking like this:
>>
>> project/major/module/minor/version
>
> I would have to do some guessing in order to understand what each element is
> supposed to represent. So, in order to discuss this in any way, your
> colleague should first establish a (written!) description how he wants to use
> this and how his setup would handle things like version numbers, tags,
> releases, (feature-)branches etc.
You're pretty correct on this point and I'm almost sure he has this
discription written down. He came to me to install the linux server and
he showed me what he planned to do. I worried about the server side
effects and that's why I made the original post.
>
>> Personally I would remove major, minor and version from the structure
>> but he really wants it that way. When he starts a new major, he creates
>> the substructure again and copies the latest version to this major.
>
> What is a 'major'? What is a 'project'? What is a 'module'? Any discussion
> without first defining these terms is pointless.
The points are defined, I just wanted to make it more abstract to the
list to make it easier to understand. So here's a more detailed
description:
* project: industry this application is made for
* major: number based on the kernel version of the hardware
* module: part of the project
* minor: mostly main but can be split for a customer
* version: starts with 00 and changes when a service pack for the kernel
is applied or an extra feature is added.
>
>> As far as I understand, there's no server-side objection doing this. For
>> subversion is doesn't matters where you create your branch. Is this
>> correct?
>
> Yes.
>
>> Will it differ at the server size concerning the size of the db if we
>> use a more normal construction like this:
>>
>> project/module/{trunk,branches,tags}
>
> Not really. Server-side copies are cheap, regardless of the layout of the
> repository.
>
> Uli
>
This was my biggest question so I didn't thought giving a more detailed
description would make any sense. I'm happy to know I should not worry
about the server side effects.
Kind regards,
wimpunk.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository construction
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
On Friday 07 March 2008, wimpunk wrote:
> A college has a rather strange idea on setting up his repository and I'm
> wondering if it will cause any troubles for subversion since I'm the
> administrator.
> He's used working with SourceSafe and now he's planning to use a
> directory structure looking like this:
>
> project/major/module/minor/version
I would have to do some guessing in order to understand what each element is
supposed to represent. So, in order to discuss this in any way, your
colleague should first establish a (written!) description how he wants to use
this and how his setup would handle things like version numbers, tags,
releases, (feature-)branches etc.
> Personally I would remove major, minor and version from the structure
> but he really wants it that way. When he starts a new major, he creates
> the substructure again and copies the latest version to this major.
What is a 'major'? What is a 'project'? What is a 'module'? Any discussion
without first defining these terms is pointless.
> As far as I understand, there's no server-side objection doing this. For
> subversion is doesn't matters where you create your branch. Is this
> correct?
Yes.
> Will it differ at the server size concerning the size of the db if we
> use a more normal construction like this:
>
> project/module/{trunk,branches,tags}
Not really. Server-side copies are cheap, regardless of the layout of the
repository.
Uli
--
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/
Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org