Re: trunk/tags/branches: root vs. project level

[Hilco Wijbenga <hi...@gmail.com>]

On Wed, Oct 15, 2008 at 06:16, Andy Law <an...@roslin.ed.ac.uk> wrote:
> Stefan Fritz-2 wrote:
>>
>>>>The main clincher is that we generally run all our sub-modules as
> children
>>>>of a parent super-module. That's only possible with the root approach.
>>
>> or you define trunk/tags/branches per module-group instead of per project
>> as you would do for standalone projects ;-)
>
> If your projects genuinely are stand-alone projects then I would suggest
> that you create separate repositories for each of them, although that may be
> harder to do if you already have history within an existing repository. I
> have not done so, but I imagine that it must be possible to clone a
> repository and then remove extra stuff from each copy such that you reduce
> to 1 project per repo?

You shouldn't create multiple repositories without *very* good
reasons. Multiple repositories just means having to duplicate
authentication, backup setup, etcetera. Moreover, any kind of copying
between projects is much harder that way. If you are working on
multiple projects you'll eventually run into refactoring cases where
you want multiple projects to reuse some shared code. That's a
no-brainer in one repository but all but impossible (i.e. without
losing history) in multiple repositories.

And what do you gain? There's little advantage to having a repository
per project.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: trunk/tags/branches: root vs. project level

[Hilco Wijbenga <hi...@gmail.com>]

On Wed, Oct 15, 2008 at 08:59, Graham Leggett <mi...@sharp.fm> wrote:
> Hilco Wijbenga wrote:
>> And what do you gain? There's little advantage to having a repository
>> per project.
>
> One of the key advantages of having one repository per project is the
> ability to take a particular project offline and archive it at some point in
> the future.

Smells like YAGNI except for the "disk space at a premium" below.

> This is important in setups where disk space use is likely to be significant
> over time, such as when working with graphics within a project, or other
> binary data that cannot be efficiently stored as diffs.

That's the only good reason I can see: projects that are so inherently
different that sharing is not going to happen.

> This can also be important where disk space is at a premium, such as when
> disk space is hosted by a third party.

Fair enough (although I would be very uncomfortable having the crown
jewels under the control of some 3rd party).

You mention a very special use case for which I would agree with your
assessment. Usually, Subversion stores code in a local environment and
multiple repositories don't make sense there. It's just more work.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: trunk/tags/branches: root vs. project level

[Graham Leggett <mi...@sharp.fm>]

Hilco Wijbenga wrote:

> You shouldn't create multiple repositories without *very* good
> reasons. Multiple repositories just means having to duplicate
> authentication, backup setup, etcetera. Moreover, any kind of copying
> between projects is much harder that way. If you are working on
> multiple projects you'll eventually run into refactoring cases where
> you want multiple projects to reuse some shared code. That's a
> no-brainer in one repository but all but impossible (i.e. without
> losing history) in multiple repositories.
> 
> And what do you gain? There's little advantage to having a repository
> per project.

One of the key advantages of having one repository per project is the 
ability to take a particular project offline and archive it at some 
point in the future.

This is important in setups where disk space use is likely to be 
significant over time, such as when working with graphics within a 
project, or other binary data that cannot be efficiently stored as diffs.

This can also be important where disk space is at a premium, such as 
when disk space is hosted by a third party.

Regards,
Graham
--

Re: trunk/tags/branches: root vs. project level

[Hilco Wijbenga <hi...@gmail.com>]

On Wed, Oct 15, 2008 at 08:53, Andy Law <an...@roslin.ed.ac.uk> wrote:
> hilco wrote:
>>> If your projects genuinely are stand-alone projects then I would suggest
>>> that you create separate repositories for each of them, although that may
>>> be
>>> harder to do if you already have history within an existing repository. I
>>> have not done so, but I imagine that it must be possible to clone a
>>> repository and then remove extra stuff from each copy such that you
>>> reduce
>>> to 1 project per repo?
>>
>> You shouldn't create multiple repositories without *very* good
>> reasons. Multiple repositories just means having to duplicate
>> authentication, backup setup, etcetera. Moreover, any kind of copying
>> between projects is much harder that way. If you are working on
>> multiple projects you'll eventually run into refactoring cases where
>> you want multiple projects to reuse some shared code. That's a
>> no-brainer in one repository but all but impossible (i.e. without
>> losing history) in multiple repositories.
>
> No problem with authentication and backup in our hands - its perfectly
> possible to run multiple repositories within the same setup on the same
> machine.

I didn't say it was impossible, I said it was more work for no gain.

> Some would also suggest that your use case of shared code screams out for a
> new artifact in its own independent space and shared across the projects
> that way.

Obviously, I agree. It's just that our definition of "independent
space" differs. :-)

> hilco wrote:
>> And what do you gain? There's little advantage to having a repository
>> per project.
>
> Independence of code, security from accidental updates whilst the entire
> repository is checked out.... :o}

Code independence has nothing to do with repositories. If you need a
dependency in your code then whether said dependency is in a separate
repository isn't relevant.

I don't understand the accidental update argument. You check out
entire repositories??? And what's an "accidental" update? You may have
a seriously weird way of working that I simply have never considered.
;-)

> Like perl, there's always more than one way to do it in the maven and
> subversion world. And no way is right or wrong as long as it works for you
> (or doesn't).

Sure, I'm just trying to save people some work. But I don't have to do
their work so it's all fine with me. :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: trunk/tags/branches: root vs. project level

[Andy Law <an...@roslin.ed.ac.uk>]

hilco wrote:
> 
>> If your projects genuinely are stand-alone projects then I would suggest
>> that you create separate repositories for each of them, although that may
>> be
>> harder to do if you already have history within an existing repository. I
>> have not done so, but I imagine that it must be possible to clone a
>> repository and then remove extra stuff from each copy such that you
>> reduce
>> to 1 project per repo?
> 
> You shouldn't create multiple repositories without *very* good
> reasons. Multiple repositories just means having to duplicate
> authentication, backup setup, etcetera. Moreover, any kind of copying
> between projects is much harder that way. If you are working on
> multiple projects you'll eventually run into refactoring cases where
> you want multiple projects to reuse some shared code. That's a
> no-brainer in one repository but all but impossible (i.e. without
> losing history) in multiple repositories.
> 
> 

No problem with authentication and backup in our hands - its perfectly
possible to run multiple repositories within the same setup on the same
machine.

Some would also suggest that your use case of shared code screams out for a
new artifact in its own independent space and shared across the projects
that way.



hilco wrote:
> 
> And what do you gain? There's little advantage to having a repository
> per project.
> 
> 

Independence of code, security from accidental updates whilst the entire
repository is checked out.... :o}


Like perl, there's always more than one way to do it in the maven and
subversion world. And no way is right or wrong as long as it works for you
(or doesn't).

Later,

Andy
-- 
View this message in context: http://www.nabble.com/trunk-tags-branches%3A--root-vs.--project-level-tp19989397p19996403.html
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org