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 |