1 |
Peter Volkov wrote: |
2 |
> ?? ??????, 13/04/2010 ?? 17:18 +0530, Nirbheek Chauhan ??????????: |
3 |
> > The traditional ChangeLog that is currently employed in gentoo-x86 |
4 |
> > (and in other projects) is simply an ugly hack |
5 |
> |
6 |
> The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used |
7 |
> in other projects is |
8 |
|
9 |
I think another very important distinction (that you imply below, |
10 |
but I want to specifically point out here) is that we have *many* |
11 |
per-project ChangeLogs whereas most other projects have a |
12 |
*single* monolithic ChangeLog. |
13 |
|
14 |
> > Think of it like this: if you make a typo in a commit message, or |
15 |
> > forget to add something; you can't change it after you've published |
16 |
> > the commit (cvs/svn commit or git push) to the world. |
17 |
> |
18 |
> And then it's better to keep ChangeLogs. For developers it was never a |
19 |
> problem to script `echangelog "log" && repoman commit -m "log"` and |
20 |
> conflict resolution is really not that hard with git. In spirit of |
21 |
> Gentoo, it's better to write some tool to update Manifests after |
22 |
> conflict resolution instead of making ChangeLogs less useful for those |
23 |
> who uses them. |
24 |
|
25 |
This is a very good point regarding ease of conflict resolution. |
26 |
|
27 |
Further to my other point above, the traditional ChangeLog |
28 |
ugliness really only hits you with a centralized setup+git if |
29 |
*everyone* is editing the *same* ChangeLog: If every commit |
30 |
touches the same file in the same place (ie, prepending to a |
31 |
ChangeLog file in the same location), you are guaranteed to have |
32 |
collisions every time you pull a new version of the file. This |
33 |
is why most projects with a single monolithic changelog |
34 |
auto-generate them, or perhaps just craft them at release time. |
35 |
|
36 |
Our case, though it is a centralized repository model, is quite |
37 |
different. The chance of collisions in a package-specific |
38 |
ChangeLog is, as it is today with CVS, pretty unlikely. In fact, |
39 |
I think the only time it usually happens to me is when an arch |
40 |
stabilizes my package while I'm making a change, and these are |
41 |
very easy to fix. |
42 |
|
43 |
(In fact, it may be possible to help git out with this specific |
44 |
ChangeLog situation by using a "custom merge driver", see |
45 |
GITATTRIBUTES(5) for details, though deployment of a custom merge |
46 |
driver can be tricky) |
47 |
|
48 |
> BTW as for profiles ChangeLogs... May be it's better to generate them. |
49 |
|
50 |
That's another important distinction and probably a good idea. I |
51 |
think those profile ChangeLogs are also not as user-facing as the |
52 |
per-package ones, so an autogenerated one makes a lot of sense. |
53 |
|
54 |
-- |
55 |
Jim Ramsay |
56 |
Gentoo/Linux Developer (rox/fluxbox/gkrellm) |