You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Santiago Gala <sg...@apache.org> on 2008/02/20 10:40:10 UTC
RE: Subversion vs other source control systems
El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> Endre Stølsvik wrote:
>
> > I find the decision to use one single SVN repo for the entire
> > organization's source pretty strange. I'd believe that one repo
> > for every TLP
>
> Been there, done that, have the scars.
>
Possibly using several *centralized* repositories that can't merge. May
we know more? If not, I call FUD ask the jury to ignore the
statement. :)
> > The only downside I see is a slight bit more configuration management
>
> Don't be so blithe about that.
>
I actually think management would be way smaller. And, what is more
important, distributable per repository.
> > and that copying/moving a file from one repo to another would not keep history
>
> Unacceptable to lose it, IMO.
>
Can be done without losing history. See separate email. And I have done
the same test with hg (basically the same) and bazaar (which required
some command line tweaking, but doable).
> And you'd be surprised how often things move around.
>
If you take a look into the basic development model in the linux kernel,
it means moving history between repositories continuously (say from am
to net to linus,...) Every line of code is tracked while it moves, in
fact when Linus merges from, say, the acpi tree, the commits remain
identical.
Regards
Santiago (I add cc: and reply-to: community)
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Subversion vs other source control systems
Posted by sebb <se...@gmail.com>.
[Apologies to incubator readers if you get this twice]
On 20/02/2008, Santiago Gala <sg...@apache.org> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>
Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.
Switching between different repositories to work on them will generate
some overhead (if only having to think about it).
Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?
The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.
> > > and that copying/moving a file from one repo to another would not keep history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)
Thanks.
> > --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Subversion vs other source control systems
Posted by sebb <se...@gmail.com>.
[Apologies to incubator readers if you get this twice]
On 20/02/2008, Santiago Gala <sg...@apache.org> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>
Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.
Switching between different repositories to work on them will generate
some overhead (if only having to think about it).
Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?
The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.
> > > and that copying/moving a file from one repo to another would not keep history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)
Thanks.
> > --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion vs other source control systems
Posted by sebb <se...@gmail.com>.
On 20/02/2008, Santiago Gala <sg...@apache.org> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>
Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.
Switching between different repositories to work on them will generate
some overhead (if only having to think about it).
Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?
The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.
> > > and that copying/moving a file from one repo to another would not keep history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)
Thanks.
> > --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org