Gentoo Archives: gentoo-dev

From: Christian Parpart <trapni@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion?
Date: Mon, 11 Apr 2005 21:32:36
Message-Id: 200504112332.23706.trapni@gentoo.org
In Reply to: Re: [gentoo-dev] GLEP 36: providing both CVS and Subversion? by Ciaran McCreesh
1 On Monday 11 April 2005 10:42 pm, Ciaran McCreesh wrote:
2 > On Mon, 11 Apr 2005 22:23:29 +0200 Christian Parpart <trapni@g.o>
3 >
4 > wrote:
5 > | On Monday 11 April 2005 8:26 am, Ciaran McCreesh wrote:
6 > | > On Sun, 10 Apr 2005 23:57:12 +0200 Christian Parpart
7 > | > <trapni@g.o>
8 > | >
9 > | > wrote:
10 > | > | > SVN uses transactions and
11 > | > | > changesets. These make a heck of a lot more sense if they're
12 > | > | > done on a per project basis.
13 > | > |
14 > | > | reason?
15 > | >
16 > | > Because you can pull out a meaningful and relevant changeset without
17 > | > having to arse around with path prefixes.
18 > |
19 > | Do you have to? If so, why?
20 >
21 > Well, surprisingly enough, one of the main reasons we use these version
22 > control things is so that we can see *what changed*. It's a hell of a
23 > lot easier to do this when you can just say "show me everything that
24 > changed in the foo project between three days ago and today" rather than
25 > having to worry about adding in extra selections to pick a project path.
26
27 yeah ;)
28
29 > | > | > Unlike with CVS, this makes a big difference -- SVN
30 > | > | > revision IDs are actually meaningful,
31 > | > |
32 > | > | SVN repository IDs represent the state of the whole repository at
33 > | > | a given time, nothing more or less.
34 > | >
35 > | > Not repo IDs. Revision IDs.
36 > |
37 > | That's the one I meant. yeah.
38 >
39 > And, said revision IDs are useful for keeping track of what's changed.
40 > Or, at least, they are if you know that an update of 3 in the revision
41 > number is equivalent to three changesets, which you don't if you use
42 > multiple projects per repo.
43
44 This eases the understanding of course. However, sometimes moving file X from
45 project foo to bar makes sense. I do not say that *you* will be in such
46 situation, but I know I already went in. And besides, I'm (not related to
47 gentoo) keeping multiple repositories for different projects and (where it
48 makes sense) project categories.
49
50 > | > | Hmm... besides, the ASF is just having a single repository for all
51 > | > | their public projects (with about 1000+ contributors) w/o any
52 > | > | problems.
53 > | >
54 > | > So we should make the same mistakes as them? Sure, a single repo
55 > | > would be usable, but multiple repos would be a heck of a lot better.
56 > |
57 > | Seriousely, this is plain low FUD unless you can give me a decent
58 > | argument on why the ASF made a mistake here.
59 >
60 > One big repository is harder to work with. It's that simple.
61
62 Might be personal taste, I can't feel here with you, but this is *all* not
63 part of GLEP36. So, let's break here the loop ;)
64
65 Regards,
66 Christian Parpart.
67
68 --
69 Netiquette: http://www.ietf.org/rfc/rfc1855.txt
70 23:25:53 up 19 days, 12:32, 4 users, load average: 0.94, 0.71, 0.65