On Wed, May 31, 2006 at 11:00:22PM -0700, larry price wrote:
> is it better to have one big repository with multiple projects, or
> should each project get it's own repository?
>
> one big repository is easier to backup and easier to screw up,
> multiple repositories can be treated with fine grain
Allen Brown wrote:
> I don't know if subversion provides better ways to do this,
> or even if it is possible.
That's pretty much Subversion's whole point. SVN is CVS with mv and
rm operators. (and other features, but those are two of the most
important.)
--
Bob Miller
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of larry price
> Sent: Thursday, June 01, 2006 12:56 AM
> To: Eugene Unix and Gnu/Linux User Group
> Subject: Re: [Eug-lug] subversion repository design
>
> On 5/31/06, Rob
larry price wrote:
I have been kind of interested in both hg and bzr as possible
alternatives hg in particular looks like it would be good for trading
changesets around in a way that svn just would not be able to handle.
I've been watching bzr-ng. It actually looks really useful for if you
do
Ben Barrett wrote:
[cut]
One Last Idea: Maybe it is not so easy to move pieces between repositories
(as it is to move pieces between "projects" if they're in the same
repository)?? I'm not as experienced at SVN as I am with CVS,
unfortunately, so I'll expect other responses... but if your projec
On 5/31/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
I like the one big repository model. We do that at Orcas and have
subdirectories off that that for tags, trunk, or branches. Under that
we have department, the projects, etc...
That's what I'm going with in this instance, it seems simpler and
Sorry, yes -- KBob++I was addressing the already-beaten-to-death deal of keeping things in separate projects/modules; one repository per organization should suffice except when say accounting/military/mafia has some kind of liability with the VCS :)
BOn 5/31/06, [EMAIL PROTECTED] wrote:
More sma
larry price wrote:
is it better to have one big repository with multiple projects, or
should each project get it's own repository?
I like the one big repository model. We do that at Orcas and have
subdirectories off that that for tags, trunk, or branches. Under that
we have department, the
More smaller ones! There are a multitude of backup methods as you know, and multiple dirs can be grouped, symlinked, stored in arrays or hashes...Among the Many Plusses:1. ACL granularity: although you mentioned this, I wanted to promote subversion for handling this gracefully; if anyone has main
larry price wrote:
> is it better to have one big repository with multiple projects, or
> should each project get it's own repository?
One repository per organization. If you're Megacorp Inc., then merge
all your projects onto the same Perforce server. If you're the Linux
Kernel, then every dev
10 matches
Mail list logo
