2.6.7
Tomasz Wittner
lists w mmt.pl
Wto, 22 Cze 2004, 16:54:30 CEST
On Tuesday 22 of June 2004 16:12, Adam Gołębiowski wrote:
> On Tue, Jun 22, 2004 at 03:00:45PM +0200, Tomasz Wittner wrote:
> > On Tuesday 22 of June 2004 00:28, Adam Gołębiowski wrote:
> > > On Mon, Jun 21, 2004 at 11:42:59PM +0200, Tomasz Wittner wrote:
[...]
> > To tak, jakby trzymać w oddzielnych
> > specach, to, co jest aktualnie na RA-branch.
>
> Zgadza się. Od tego są branche. Ale nie oznacza to, że koniecznie bez
> dwóch zdań musimy z nich korzystać. Jeśli wygodniej korzysta się z
> oddzielnych plików, to ... czemu nie?
Się powtórzę po raz n-ty: IMHO ze względu na identyczne nazwy niektórych paczy
dla kerneli, które mogą różnić się zawartości i których nazw, IMHO, nie ma
sensu duplikować (w dodatku jeden nazwie linux24-foo.patch, drugi
linux2.4-... albo będzie to w jednej i drugiej postaci -> zamieszanie. cvs
trzyma różnicę w postaci RCS -> oszczędność miejsca (zazwyczaj), mamy wspólne
SOURCES -> mnożenie ilości plików -> im więcej plików, tym gorzej dla cvsweb,
dłużej się ładuje strona www z SOURCES, może więcej czasu Ci zajmuje
znalezienie właściwego pliku - niby banały, ale ... . Minusem jest to, ze
konfiguracja naszego cvsweb nie ma filtrowania pt: "Show only files with
tag:" i strona z takim "jebutnym" Changelogiem, jak ma kernel.spec też się
szybko nie ładuje.
>
> Doprowadzając do absurdu - czemu nie zrobić pld.spec z tak około 7000
> branchy? ;)
Bo to absurd :) i nie to jest motywacją dla branchy. Trzeba znaleźć jakiś
środek [1] (niekoniecznie złoty) między trzymaniem wszystkiego na branchach,
a trzymaniem wszystkiego w osobnych plikach (skrajność w drugą stronę). Z
mojej strony: temu służy dyskusja i przedstawianie swoich argumentów, by się
nad tym zastanowić nad optymalnym rozwiązaniem, potencjalnymi problemami, a
nie temu, żeby stanęło na akurat na moim. A swoje argumenty przedstawiłem,
mam nadzieję, że jasno. A nieprzekonanych i tak się nie da przekonać ;).
[1] środek leży, tam gdzie ja mowię ;-D
--
Tomasz Wittner
Więcej informacji o liście dyskusyjnej pld-devel-pl