| 1 |
Steve Long wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> Please note, I'm not talking about applications like portage or pkgcore, |
| 5 |
> just the ebuild text files, which I understand have one maintainer? |
| 6 |
> |
| 7 |
|
| 8 |
Many ebuilds are in maintained by a bunch of people via herds. |
| 9 |
|
| 10 |
> |
| 11 |
> I appreciate that source control is needed to maintain files over a period |
| 12 |
> of time and to roll back changes. Does that happen with ebuilds? |
| 13 |
> |
| 14 |
|
| 15 |
Rolling back changes does not happen that often but a history is useful. |
| 16 |
|
| 17 |
> |
| 18 |
> I'm thinking in any case that a db app can save old revisions or use a svn |
| 19 |
> backend. I'm looking at this from a workflow perspective, in terms |
| 20 |
> especially of the security issue around giving commit access to the whole |
| 21 |
> tree. If the individual maintainer only has permission for those ebuilds |
| 22 |
> s/he is responsible for, it might make it easier to allow new people write |
| 23 |
> access. |
| 24 |
> |
| 25 |
|
| 26 |
I fail to see any benefit from a layer above svn. svn has good access |
| 27 |
control if we want use that built in. |
| 28 |
|
| 29 |
> |
| 30 |
> Sorry if this has all been discussed before. |
| 31 |
> |
| 32 |
|
| 33 |
Most likely the access control has been discusses some times before. To |
| 34 |
summarize having access to everything is quite useful. |
| 35 |
|
| 36 |
> |
| 37 |
> (Please note: I'm not discussing the mechanisms by which software might be |
| 38 |
> installed for the end-user, rather the back-end which you devs use, of |
| 39 |
> which I admittedly have no experience.) |
| 40 |
> |
| 41 |
|
| 42 |
So please let people who actually use/know how source control work |
| 43 |
discuss the issue. |
Archives