Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?

[Christian Parpart <trapni@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

On Monday 11 April 2005 10:42 pm, Ciaran McCreesh wrote:
> On Mon, 11 Apr 2005 22:23:29 +0200 Christian Parpart <trapni@gentoo.org>
>
> wrote:
> | On Monday 11 April 2005 8:26 am, Ciaran McCreesh wrote:
> | > On Sun, 10 Apr 2005 23:57:12 +0200 Christian Parpart
> | > <trapni@gentoo.org>
> | >
> | > wrote:
> | > | > SVN uses transactions and
> | > | > changesets. These make a heck of a lot more sense if they're
> | > | > done on a per project basis.
> | > |
> | > | reason?
> | >
> | > Because you can pull out a meaningful and relevant changeset without
> | > having to arse around with path prefixes.
> |
> | Do you have to? If so, why?
>
> Well, surprisingly enough, one of the main reasons we use these version
> control things is so that we can see *what changed*. It's a hell of a
> lot easier to do this when you can just say "show me everything that
> changed in the foo project between three days ago and today" rather than
> having to worry about adding in extra selections to pick a project path.

yeah ;)

> | > | > Unlike with CVS, this makes a big difference -- SVN
> | > | > revision IDs are actually meaningful,
> | > |
> | > | SVN repository IDs represent the state of the whole repository at
> | > | a given  time, nothing more or less.
> | >
> | > Not repo IDs. Revision IDs.
> |
> | That's the one I meant. yeah.
>
> And, said revision IDs are useful for keeping track of what's changed.
> Or, at least, they are if you know that an update of 3 in the revision
> number is equivalent to three changesets, which you don't if you use
> multiple projects per repo.

This eases the understanding of course. However, sometimes moving file X from 
project foo to bar makes sense. I do not say that *you* will be in such 
situation, but I know I already went in. And besides, I'm (not related to 
gentoo) keeping multiple repositories for different projects and (where it 
makes sense) project categories.

> | > | Hmm... besides, the ASF is just having a single repository for all
> | > | their  public projects (with about 1000+ contributors) w/o any
> | > | problems.
> | >
> | > So we should make the same mistakes as them? Sure, a single repo
> | > would be usable, but multiple repos would be a heck of a lot better.
> |
> | Seriousely, this is plain low FUD unless you can give me a decent
> | argument on  why the ASF made a mistake here.
>
> One big repository is harder to work with. It's that simple.

Might be personal taste, I can't feel here with you, but this is *all* not 
part of GLEP36. So, let's break here the loop ;)

Regards,
Christian Parpart.

-- 
Netiquette: http://www.ietf.org/rfc/rfc1855.txt
 23:25:53 up 19 days, 12:32,  4 users,  load average: 0.94, 0.71, 0.65

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]