SVN i projket składany z kawałków
Sebastian Biały - 24-12-2006 01:15
SVN i projket składany z kawałków
Witam!
Taka sprawa:
Mam 2 projekty: A i B. Obydwa korzystają ze wspólnej biblioteki X, choć
są w zasadzie mocno różne i nigdy nie będa stanowiły całości.
Wszystkie projkety A,B i X powinny być pod kontrolą SVN.
X jest jednym z podkatalogów w źródłach A i B (i wolałbym żeby tak
zostało, bo to jest zdecydowanie bardziej naturalne).
Mam serwer SVN. Nie chce coś popsuć, więc zapytam o to czy koncepcję mam
słuszną:
Projekty A,B i X są trzymane w SVN osobno.
Aby zrobić checkout na A to robie checkout :), tworze katalog dla X i
robie checkout X w tym katalogu. Dostaje co chce, ale efektem tego
repozytorium A na dysku jest "inne" niż na serwerze.
Niestety jest to metoda ręczna i nieciekawa.
Pytanie wobec tego: czy moja koncepcja nie kłuci się z filozofią SVN a w
szczególnoci czy można to rozwiązać lepiej?
Od razu mówie, że ściąganie całości, aby ściągnąć A nie ma sensu.
Chciałbym mieć te trzy projekty możliwie niezależne, ale jednocześnie
przy checkout A chciałbym mieć od razu X. Podobnie checkout B - od razu
X. No i oczywiście X w jednej kopii na serwerze. Dłubie od paru godzin
po dokumentacji i jakoś nie mogę znaleźć sensownego opisu mojego
problemu i rozwiązania możliwie bez kombinowania.
sg - 24-12-2006 01:15
Sebastian Biały napisał(a):
> Witam!
>
> Taka sprawa:
>
> Mam 2 projekty: A i B. Obydwa korzystają ze wspólnej biblioteki X, choć
> są w zasadzie mocno różne i nigdy nie będa stanowiły całości.
>
> Wszystkie projkety A,B i X powinny być pod kontrolą SVN.
>
> X jest jednym z podkatalogów w źródłach A i B (i wolałbym żeby tak
> zostało, bo to jest zdecydowanie bardziej naturalne).
>
> Mam serwer SVN. Nie chce coś popsuć, więc zapytam o to czy koncepcję mam
> słuszną:
>
> Projekty A,B i X są trzymane w SVN osobno.
>
> Aby zrobić checkout na A to robie checkout :), tworze katalog dla X i
> robie checkout X w tym katalogu. Dostaje co chce, ale efektem tego
> repozytorium A na dysku jest "inne" niż na serwerze.
>
> Niestety jest to metoda ręczna i nieciekawa.
>
> Pytanie wobec tego: czy moja koncepcja nie kłuci się z filozofią SVN a w
> szczególnoci czy można to rozwiązać lepiej?
>
> Od razu mówie, że ściąganie całości, aby ściągnąć Anie ma sensu.
> Chciałbym mieć te trzy projekty możliwie niezależne, ale jednocześnie
> przy checkout A chciałbym mieć od razu X. Podobnie checkout B - od razu
> X. No i oczywiście X w jednej kopii na serwerze. Dłubie od paru godzin
> po dokumentacji i jakoś nie mogę znaleźć sensownego opisu mojego
> problemu i rozwiązania możliwie bez kombinowania.
to w ogóle jest bez sensu. Skoro X to biblioteka to trzymaj to na tym
samym poziomie katalogów o A i B. Wtedy masz 3 niezależne projekty i z
niczym się to nie kłóci.
Jak chcesz mieć automatyczny checkout AX i BX to napisz sobie prosty
skrypcik w shellu, który to zrobi automatycznie
sg - 24-12-2006 01:15
Sebastian Biały napisał(a):
> Witam!
>
> Taka sprawa:
>
> Mam 2 projekty: A i B. Obydwa korzystają ze wspólnej biblioteki X, choć
> są w zasadzie mocno różne i nigdy nie będa stanowiły całości.
>
> Wszystkie projkety A,B i X powinny być pod kontrolą SVN.
>
> X jest jednym z podkatalogów w źródłach A i B (i wolałbym żeby tak
> zostało, bo to jest zdecydowanie bardziej naturalne).
>
> Mam serwer SVN. Nie chce coś popsuć, więc zapytam o to czy koncepcję mam
> słuszną:
>
> Projekty A,B i X są trzymane w SVN osobno.
>
> Aby zrobić checkout na A to robie checkout :), tworze katalog dla X i
> robie checkout X w tym katalogu. Dostaje co chce, ale efektem tego
> repozytorium A na dysku jest "inne" niż na serwerze.
>
> Niestety jest to metoda ręczna i nieciekawa.
>
> Pytanie wobec tego: czy moja koncepcja nie kłuci się z filozofią SVN a w
> szczególnoci czy można to rozwiązać lepiej?
>
> Od razu mówie, że ściąganie całości, aby ściągnąć Anie ma sensu.
> Chciałbym mieć te trzy projekty możliwie niezależne, ale jednocześnie
> przy checkout A chciałbym mieć od razu X. Podobnie checkout B - od razu
> X. No i oczywiście X w jednej kopii na serwerze. Dłubie od paru godzin
> po dokumentacji i jakoś nie mogę znaleźć sensownego opisu mojego
> problemu i rozwiązania możliwie bez kombinowania.
to w ogóle jest bez sensu. Skoro X to biblioteka to trzymaj to na tym
samym poziomie katalogów o A i B. Wtedy masz 3 niezależne projekty i z
niczym się to nie kłóci.
Jak chcesz mieć automatyczny checkout AX i BX to napisz sobie prosty
skrypcik w shellu, który to zrobi automatycznie
Sebastian Biały - 24-12-2006 01:15
sg wrote:
> to w ogóle jest bez sensu. Skoro X to biblioteka to trzymaj to na tym
> samym poziomie katalogów o A i B. Wtedy masz 3 niezależne projekty i z
> niczym się to nie kłóci.
> Jak chcesz mieć automatyczny checkout AX i BX to napisz sobie prosty
> skrypcik w shellu, który to zrobi automatycznie
Owszem mam tak teraz, ale ponieważ developing prowadzę ostatnio również
na windowsie to prosty skrypcik staje się nietrywialnym zaganieniem :)
Wiem wiem, że można ...
A całkiem serio: Chciałbym aby pliki projektu X wylądowały wewnatrz
źródeł A i B. Nie na wspólnym poziomie tylko własnie w głębi. I abym
robiąc "commit" na A zacommitował również X w środku.
Sebastian Biały - 24-12-2006 01:15
sg wrote:
> to w ogóle jest bez sensu. Skoro X to biblioteka to trzymaj to na tym
> samym poziomie katalogów o A i B. Wtedy masz 3 niezależne projekty i z
> niczym się to nie kłóci.
> Jak chcesz mieć automatyczny checkout AX i BX to napisz sobie prosty
> skrypcik w shellu, który to zrobi automatycznie
Owszem mam tak teraz, ale ponieważ developing prowadzę ostatnio również
na windowsie to prosty skrypcik staje się nietrywialnym zaganieniem :)
Wiem wiem, że można ...
A całkiem serio: Chciałbym aby pliki projektu X wylądowały wewnatrz
źródeł A i B. Nie na wspólnym poziomie tylko własnie w głębi. I abym
robiąc "commit" na A zacommitował również X w środku.
sg - 24-12-2006 01:15
Sebastian Biały napisał(a):
> sg wrote:
>> to w ogóle jest bez sensu. Skoro X to biblioteka to trzymaj to na tym
>> samym poziomie katalogów o A i B. Wtedy masz 3 niezależne projektyi z
>> niczym się to nie kłóci.
>> Jak chcesz mieć automatyczny checkout AX i BX to napisz sobie prosty
>> skrypcik w shellu, który to zrobi automatycznie
>
> Owszem mam tak teraz, ale ponieważ developing prowadzę ostatnio również
> na windowsie to prosty skrypcik staje się nietrywialnym zaganieniem :)
> Wiem wiem, że można ...
serio? prosty plik co.bat z dwoma linijkami? w pierwszej linii wpisujesz:
svn.exe rep A
a w drugiej
svn.exe rep A\X
czy jakoś tak. Kiedyś przebrnąłem przez takie proste skrypty i naprawdę
nie jest to trudne :)
>
> A całkiem serio: Chciałbym aby pliki projektu X wylądowały wewnatrz
> źródeł A i B. Nie na wspólnym poziomie tylko własnie w głębi. I abym
> robiąc "commit" na A zacommitował również X w środku.
ech, takie rzeczy to tylko w erze... nie da się... chyba, że zrobisz
sobie taki automatyczny skrypcik :)
sg - 24-12-2006 01:15
Sebastian Biały napisał(a):
> sg wrote:
>> to w ogóle jest bez sensu. Skoro X to biblioteka to trzymaj to na tym
>> samym poziomie katalogów o A i B. Wtedy masz 3 niezależne projektyi z
>> niczym się to nie kłóci.
>> Jak chcesz mieć automatyczny checkout AX i BX to napisz sobie prosty
>> skrypcik w shellu, który to zrobi automatycznie
>
> Owszem mam tak teraz, ale ponieważ developing prowadzę ostatnio również
> na windowsie to prosty skrypcik staje się nietrywialnym zaganieniem :)
> Wiem wiem, że można ...
serio? prosty plik co.bat z dwoma linijkami? w pierwszej linii wpisujesz:
svn.exe rep A
a w drugiej
svn.exe rep A\X
czy jakoś tak. Kiedyś przebrnąłem przez takie proste skrypty i naprawdę
nie jest to trudne :)
>
> A całkiem serio: Chciałbym aby pliki projektu X wylądowały wewnatrz
> źródeł A i B. Nie na wspólnym poziomie tylko własnie w głębi. I abym
> robiąc "commit" na A zacommitował również X w środku.
ech, takie rzeczy to tylko w erze... nie da się... chyba, że zrobisz
sobie taki automatyczny skrypcik :)
Sebastian Biały - 24-12-2006 01:15
sg wrote:
> serio? prosty plik co.bat z dwoma linijkami?
Przypadek z dwoma projektami jest ... powiedzmy ... brzegowy. Aktualnie
tego jest 5-6 sztuk. W dodatku na windowsie preferuje Tortoise do SVN.
Więc skrypty srednipo pasują. I dalej mam pytanie, czy "zgodne" ze
sztuką jest checkout jednego projektu w bebechy innego. Szukam
eleganckiego rozwiązania.
> ech, takie rzeczy to tylko w erze... nie da się... chyba, że zrobisz
> sobie taki automatyczny skrypcik :)
No ładnie :/ W zasadzie potrzebuje odpowiednik soft-link w repozytorium.
Rozwiązało by mi to sporo problemów. W dokumentacji nie potrafie się
tego doszukać.
Sebastian Biały - 24-12-2006 01:15
sg wrote:
> serio? prosty plik co.bat z dwoma linijkami?
Przypadek z dwoma projektami jest ... powiedzmy ... brzegowy. Aktualnie
tego jest 5-6 sztuk. W dodatku na windowsie preferuje Tortoise do SVN.
Więc skrypty srednipo pasują. I dalej mam pytanie, czy "zgodne" ze
sztuką jest checkout jednego projektu w bebechy innego. Szukam
eleganckiego rozwiązania.
> ech, takie rzeczy to tylko w erze... nie da się... chyba, że zrobisz
> sobie taki automatyczny skrypcik :)
No ładnie :/ W zasadzie potrzebuje odpowiednik soft-link w repozytorium.
Rozwiązało by mi to sporo problemów. W dokumentacji nie potrafie się
tego doszukać.
sg - 24-12-2006 01:15
Sebastian Biały napisał(a):
> sg wrote:
>> serio? prosty plik co.bat z dwoma linijkami?
>
> Przypadek z dwoma projektami jest ... powiedzmy ... brzegowy. Aktualnie
> tego jest 5-6 sztuk. W dodatku na windowsie preferuje Tortoise do SVN.
> Więc skrypty srednipo pasują.
Etam, Tortoise jest fajny do ręcznej zabawy, ale jak potrzebujesz
zautomatyzować to sobie to lepiej zrobić to tak, że masz skrypty.
Do tego skoro masz 5-6 projektów i każdy korzysta z biblioteki X to może
lepiej zrobić sobie np. taki skrypcik, który automatycznie zaktualizuje
wszystkie katalogi X? A takich rzeczy tortoise nie zrobi.
A tak wogóle to bawiłeś się ręcznym wpisywaniem komend SVNa w linii
poleceń? Jeśli tak to nie będziesz mieć żadnych problemów z napisaniem
sobie takiego skryptu.
> I dalej mam pytanie, czy "zgodne" ze
> sztuką jest checkout jednego projektu w bebechy innego. Szukam
> eleganckiego rozwiązania.
>
no to nie jest eleganckie, bo automatycznie musisz sobie oznaczyć ten
katalog X żeby nie był sprawdzany przy zabawie z A.
>> ech, takie rzeczy to tylko w erze... nie da się... chyba, że zrobisz
>> sobie taki automatyczny skrypcik :)
>
> No ładnie :/ W zasadzie potrzebuje odpowiednik soft-link w repozytorium.
> Rozwiązało by mi to sporo problemów. W dokumentacji nie potrafiesię
> tego doszukać.
bo tego nie ma
sg - 24-12-2006 01:15
Sebastian Biały napisał(a):
> sg wrote:
>> serio? prosty plik co.bat z dwoma linijkami?
>
> Przypadek z dwoma projektami jest ... powiedzmy ... brzegowy. Aktualnie
> tego jest 5-6 sztuk. W dodatku na windowsie preferuje Tortoise do SVN.
> Więc skrypty srednipo pasują.
Etam, Tortoise jest fajny do ręcznej zabawy, ale jak potrzebujesz
zautomatyzować to sobie to lepiej zrobić to tak, że masz skrypty.
Do tego skoro masz 5-6 projektów i każdy korzysta z biblioteki X to może
lepiej zrobić sobie np. taki skrypcik, który automatycznie zaktualizuje
wszystkie katalogi X? A takich rzeczy tortoise nie zrobi.
A tak wogóle to bawiłeś się ręcznym wpisywaniem komend SVNa w linii
poleceń? Jeśli tak to nie będziesz mieć żadnych problemów z napisaniem
sobie takiego skryptu.
> I dalej mam pytanie, czy "zgodne" ze
> sztuką jest checkout jednego projektu w bebechy innego. Szukam
> eleganckiego rozwiązania.
>
no to nie jest eleganckie, bo automatycznie musisz sobie oznaczyć ten
katalog X żeby nie był sprawdzany przy zabawie z A.
>> ech, takie rzeczy to tylko w erze... nie da się... chyba, że zrobisz
>> sobie taki automatyczny skrypcik :)
>
> No ładnie :/ W zasadzie potrzebuje odpowiednik soft-link w repozytorium.
> Rozwiązało by mi to sporo problemów. W dokumentacji nie potrafiesię
> tego doszukać.
bo tego nie ma
Marcin 'Qrczak' Kowalczyk - 24-12-2006 01:15
Sebastian Biały <heby@poczta.onet.pl> writes:
> X jest jednym z podkatalogów w źródłach A i B (i wolałbym żeby tak
> zostało, bo to jest zdecydowanie bardziej naturalne).
Porzuć to założenie i życie stanie się prostsze.
--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk - 24-12-2006 01:15
Sebastian Biały <heby@poczta.onet.pl> writes:
> X jest jednym z podkatalogów w źródłach A i B (i wolałbym żeby tak
> zostało, bo to jest zdecydowanie bardziej naturalne).
Porzuć to założenie i życie stanie się prostsze.
--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Sebastian Bialy - 24-12-2006 01:15
Marcin 'Qrczak' Kowalczyk wrote:
> Porzuć to założenie i życie stanie się prostsze.
To jedna z opcji. Ale poszukam jeszcze, nie poddaje się łatwo :) Wbrew
pozorom zdecydowanie wygodniej tworzy mi się _ten_ zestaw programów
zakładając hierarchiczną budowę katalogów ze źródłami.
Sebastian Bialy - 24-12-2006 01:15
Marcin 'Qrczak' Kowalczyk wrote:
> Porzuć to założenie i życie stanie się prostsze.
To jedna z opcji. Ale poszukam jeszcze, nie poddaje się łatwo :) Wbrew
pozorom zdecydowanie wygodniej tworzy mi się _ten_ zestaw programów
zakładając hierarchiczną budowę katalogów ze źródłami.
sg - 24-12-2006 01:15
Sebastian Bialy napisał(a):
> Marcin 'Qrczak' Kowalczyk wrote:
>> Porzuć to założenie i życie stanie się prostsze.
>
> To jedna z opcji. Ale poszukam jeszcze, nie poddaje się łatwo :) Wbrew
> pozorom zdecydowanie wygodniej tworzy mi się _ten_ zestaw programów
> zakładając hierarchiczną budowę katalogów ze źródłami.
tworzyć to może i łatwiej, ale rozumiem, że nie musiałeś w żadnej takiej
konfiguracji mieszać dłużej niż kilka dni. Jak ci się to rozrośnie na
20-30 projektów z czego większość to biblioteki, to też będziesz tak robił?
sg - 24-12-2006 01:15
Sebastian Bialy napisał(a):
> Marcin 'Qrczak' Kowalczyk wrote:
>> Porzuć to założenie i życie stanie się prostsze.
>
> To jedna z opcji. Ale poszukam jeszcze, nie poddaje się łatwo :) Wbrew
> pozorom zdecydowanie wygodniej tworzy mi się _ten_ zestaw programów
> zakładając hierarchiczną budowę katalogów ze źródłami.
tworzyć to może i łatwiej, ale rozumiem, że nie musiałeś w żadnej takiej
konfiguracji mieszać dłużej niż kilka dni. Jak ci się to rozrośnie na
20-30 projektów z czego większość to biblioteki, to też będziesz tak robił?
Sebastian Bialy - 24-12-2006 01:15
sg wrote:
> tworzyć to może i łatwiej, ale rozumiem, że nie musiałeś w żadnej takiej
> konfiguracji mieszać dłużej niż kilka dni. Jak ci się to rozrośnie na
> 20-30 projektów z czego większość to biblioteki, to też będziesz tak robił?
Nie - to dość specyficzny problem. Z jednego kawałka kodu w C/C++
korzystają targety na uC i na normalny OS. Sa na tyle różne, że nie mają
innych częsci stykowych. Ta wymienna część to zaledwie pare plików
..h/.cpp zapewniających wspólny pomost komunikacyjny. Z pewnych względów
(głównie uC) nie jest mi wygodnie generować biblioteki
..so/.dll/.o/whatever, wole umieścić część razem z resztą kodu uC (dla
zainteresowanych: trzeba ten sam kawałek .cpp przekopilować N razy dla
różnych kwarców/uC/konfiguracji/etc).
Oczywiście da się to zrobić "normalnie" ale ten problem przemyślałem już
pod różnymi kątami i wydaje mi się, że było by mi wygodniej zawierać X w
A i B niż korzystać równolegle.
Sebastian Bialy - 24-12-2006 01:15
sg wrote:
> tworzyć to może i łatwiej, ale rozumiem, że nie musiałeś w żadnej takiej
> konfiguracji mieszać dłużej niż kilka dni. Jak ci się to rozrośnie na
> 20-30 projektów z czego większość to biblioteki, to też będziesz tak robił?
Nie - to dość specyficzny problem. Z jednego kawałka kodu w C/C++
korzystają targety na uC i na normalny OS. Sa na tyle różne, że nie mają
innych częsci stykowych. Ta wymienna część to zaledwie pare plików
..h/.cpp zapewniających wspólny pomost komunikacyjny. Z pewnych względów
(głównie uC) nie jest mi wygodnie generować biblioteki
..so/.dll/.o/whatever, wole umieścić część razem z resztą kodu uC (dla
zainteresowanych: trzeba ten sam kawałek .cpp przekopilować N razy dla
różnych kwarców/uC/konfiguracji/etc).
Oczywiście da się to zrobić "normalnie" ale ten problem przemyślałem już
pod różnymi kątami i wydaje mi się, że było by mi wygodniej zawierać X w
A i B niż korzystać równolegle.
Deflokracja - 24-12-2006 01:15
> Od razu mówie, że ściąganie całości, aby ściągnąć A nie ma sensu.
> Chciałbym mieć te trzy projekty możliwie niezależne, ale jednocześnie
> przy checkout A chciałbym mieć od razu X. Podobnie checkout B - od razu
> X. No i oczywiście X w jednej kopii na serwerze. Dłubie od paru godzin
> po dokumentacji i jakoś nie mogę znaleźć sensownego opisu mojego
> problemu i rozwiązania możliwie bez kombinowania.
http://svnbook.red-bean.com/en/1.0/ch07s03.html
?
--
Deflokracja
http://deflokracja.blox.pl
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Deflokracja - 24-12-2006 01:15
> Od razu mówie, że ściąganie całości, aby ściągnąć A nie ma sensu.
> Chciałbym mieć te trzy projekty możliwie niezależne, ale jednocześnie
> przy checkout A chciałbym mieć od razu X. Podobnie checkout B - od razu
> X. No i oczywiście X w jednej kopii na serwerze. Dłubie od paru godzin
> po dokumentacji i jakoś nie mogę znaleźć sensownego opisu mojego
> problemu i rozwiązania możliwie bez kombinowania.
http://svnbook.red-bean.com/en/1.0/ch07s03.html
?
--
Deflokracja
http://deflokracja.blox.pl
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Sebastian Bialy - 24-12-2006 01:15
Deflokracja wrote:
>>Od razu mówie, że ściąganie całości, aby ściągnąć A nie ma sensu.
>>Chciałbym mieć te trzy projekty możliwie niezależne, ale jednocześnie
>>przy checkout A chciałbym mieć od razu X. Podobnie checkout B - od razu
>>X. No i oczywiście X w jednej kopii na serwerze. Dłubie od paru godzin
>>po dokumentacji i jakoś nie mogę znaleźć sensownego opisu mojego
>>problemu i rozwiązania możliwie bez kombinowania.
>
>
> http://svnbook.red-bean.com/en/1.0/ch07s03.html
> ?
>
Widziałem to, ale:
[...]if you want to commit changes that you've made in one or more of
those external working copies, you must run svn commit explicitly on
those working copiesâcommitting on the primary working copy will not
recurse into any external ones.
No i to połowa sukcesu, aczkolwiek blisko.
Sebastian Bialy - 24-12-2006 01:15
Deflokracja wrote:
>>Od razu mówie, że ściąganie całości, aby ściągnąć A nie ma sensu.
>>Chciałbym mieć te trzy projekty możliwie niezależne, ale jednocześnie
>>przy checkout A chciałbym mieć od razu X. Podobnie checkout B - od razu
>>X. No i oczywiście X w jednej kopii na serwerze. Dłubie od paru godzin
>>po dokumentacji i jakoś nie mogę znaleźć sensownego opisu mojego
>>problemu i rozwiązania możliwie bez kombinowania.
>
>
> http://svnbook.red-bean.com/en/1.0/ch07s03.html
> ?
>
Widziałem to, ale:
[...]if you want to commit changes that you've made in one or more of
those external working copies, you must run svn commit explicitly on
those working copiesâcommitting on the primary working copy will not
recurse into any external ones.
No i to połowa sukcesu, aczkolwiek blisko.
sg - 24-12-2006 01:15
Sebastian Bialy napisał(a):
> sg wrote:
>> tworzyć to może i łatwiej, ale rozumiem, że nie musiałeś wżadnej
>> takiej konfiguracji mieszać dłużej niż kilka dni. Jak ci sięto
>> rozrośnie na 20-30 projektów z czego większość to biblioteki, to też
>> będziesz tak robił?
>
> Nie - to dość specyficzny problem. Z jednego kawałka kodu w C/C++
> korzystają targety na uC i na normalny OS. Sa na tyle różne, żenie mają
> innych częsci stykowych. Ta wymienna część to zaledwie pare plików
> ..h/.cpp zapewniających wspólny pomost komunikacyjny. Z pewnych względów
> (głównie uC) nie jest mi wygodnie generować biblioteki
> ..so/.dll/.o/whatever, wole umieścić część razem z resztą kodu uC (dla
> zainteresowanych: trzeba ten sam kawałek .cpp przekopilować N razy dla
> różnych kwarców/uC/konfiguracji/etc).
>
> Oczywiście da się to zrobić "normalnie" ale ten problem przemyślałem już
> pod różnymi kątami i wydaje mi się, że było by mi wygodniejzawierać X w
> A i B niż korzystać równolegle.
nie, to jest wygodniejsze pod warunkiem, że nie robisz nic dużego ani
nic długiego... bo jak to będzie większy projekt to lepiej mieć globalny
katalog X (jeden) i niech każdy projekt sobie korzysta z tych plików.
Natomiast dalej będę Cię przekonywał że jak chcesz sobie zautomatyzować
SVN/CVS/whatevera to najlepiej zrobić sobie skrypty.
sg - 24-12-2006 01:15
Sebastian Bialy napisał(a):
> sg wrote:
>> tworzyć to może i łatwiej, ale rozumiem, że nie musiałeś wżadnej
>> takiej konfiguracji mieszać dłużej niż kilka dni. Jak ci sięto
>> rozrośnie na 20-30 projektów z czego większość to biblioteki, to też
>> będziesz tak robił?
>
> Nie - to dość specyficzny problem. Z jednego kawałka kodu w C/C++
> korzystają targety na uC i na normalny OS. Sa na tyle różne, żenie mają
> innych częsci stykowych. Ta wymienna część to zaledwie pare plików
> ..h/.cpp zapewniających wspólny pomost komunikacyjny. Z pewnych względów
> (głównie uC) nie jest mi wygodnie generować biblioteki
> ..so/.dll/.o/whatever, wole umieścić część razem z resztą kodu uC (dla
> zainteresowanych: trzeba ten sam kawałek .cpp przekopilować N razy dla
> różnych kwarców/uC/konfiguracji/etc).
>
> Oczywiście da się to zrobić "normalnie" ale ten problem przemyślałem już
> pod różnymi kątami i wydaje mi się, że było by mi wygodniejzawierać X w
> A i B niż korzystać równolegle.
nie, to jest wygodniejsze pod warunkiem, że nie robisz nic dużego ani
nic długiego... bo jak to będzie większy projekt to lepiej mieć globalny
katalog X (jeden) i niech każdy projekt sobie korzysta z tych plików.
Natomiast dalej będę Cię przekonywał że jak chcesz sobie zautomatyzować
SVN/CVS/whatevera to najlepiej zrobić sobie skrypty.
Michał 'Khorne' Rzechonek - 24-12-2006 01:15
Sebastian Bialy wrote:
> Widziałem to, ale:
>
> [...]if you want to commit changes that you've made in one or more of
> those external working copies, you must run svn commit explicitly on
> those working copies-committing on the primary working copy will not
> recurse into any external ones.
>
> No i to połowa sukcesu, aczkolwiek blisko.
Więcej nie dostaniesz. Linkowanie repozytoriów jest w planach,
por. http://svn.haxx.se/dev/archive-2006-06/0856.shtml, ale IIRC
na liście wyżej jest np. automatyczne śledzenie merge'ów.
--
Michał 'Khorne' Rzechonek
Michał 'Khorne' Rzechonek - 24-12-2006 01:15
Sebastian Bialy wrote:
> Widziałem to, ale:
>
> [...]if you want to commit changes that you've made in one or more of
> those external working copies, you must run svn commit explicitly on
> those working copies-committing on the primary working copy will not
> recurse into any external ones.
>
> No i to połowa sukcesu, aczkolwiek blisko.
Więcej nie dostaniesz. Linkowanie repozytoriów jest w planach,
por. http://svn.haxx.se/dev/archive-2006-06/0856.shtml, ale IIRC
na liście wyżej jest np. automatyczne śledzenie merge'ów.
--
Michał 'Khorne' Rzechonek
Kamil Burzynski - 24-12-2006 01:15
On Tue, 10 Oct 2006 18:13:40 +0200
Sebastian Biały <heby@poczta.onet.pl> wrote:
> X jest jednym z podkatalogów w źródłach A i B (i wolałbym żeby tak
> zostało, bo to jest zdecydowanie bardziej naturalne).
Jak uzyjesz WinAPI to tez bedziesz chcial zeby wszystkie include'y
i .dll byly w tym repozytorium? A jak bedziesz musial dane do Worda
exportowac, to Worda tez wsadzisz do swojego repozytorium? Ew. jesli
calosc jest mierzona glownie pod un*xy pytanie mozna odwrocic - np. czy
bedziesz kladl caly kernel linuxowy do srodka? I tak dalej...
--
Best regards from
Kamil Burzynski
Kamil Burzynski - 24-12-2006 01:15
On Tue, 10 Oct 2006 18:13:40 +0200
Sebastian Biały <heby@poczta.onet.pl> wrote:
> X jest jednym z podkatalogów w źródłach A i B (i wolałbym żeby tak
> zostało, bo to jest zdecydowanie bardziej naturalne).
Jak uzyjesz WinAPI to tez bedziesz chcial zeby wszystkie include'y
i .dll byly w tym repozytorium? A jak bedziesz musial dane do Worda
exportowac, to Worda tez wsadzisz do swojego repozytorium? Ew. jesli
calosc jest mierzona glownie pod un*xy pytanie mozna odwrocic - np. czy
bedziesz kladl caly kernel linuxowy do srodka? I tak dalej...
--
Best regards from
Kamil Burzynski
Paweł Kierski - 24-12-2006 01:15
Sebastian Biały w wiadomości <eggn5t$q5l$1@uranos.cto.us.edu.pl> pisze:
> sg wrote:
> > serio? prosty plik co.bat z dwoma linijkami?
>
> Przypadek z dwoma projektami jest ... powiedzmy ... brzegowy. Aktualnie
> tego jest 5-6 sztuk. W dodatku na windowsie preferuje Tortoise do SVN.
> Więc skrypty srednipo pasują. I dalej mam pytanie, czy "zgodne" ze
> sztuką jest checkout jednego projektu w bebechy innego. Szukam
> eleganckiego rozwiązania.
>
> > ech, takie rzeczy to tylko w erze... nie da się... chyba, że zrobisz
> > sobie taki automatyczny skrypcik :)
>
> No ładnie :/ W zasadzie potrzebuje odpowiednik soft-link w repozytorium.
> Rozwiązało by mi to sporo problemów. W dokumentacji nie potrafie się
> tego doszukać.
No właśnie - też szukałem. Tym bardziej, że bywają projekty, w
których w trakcie rozwoju pliki "wspólne" w źródłach pojawiają się w
sposobó ciężki do przewidzenia. Tylko dlatego że nagle w B potrzebuję
pliku x.h powoduje, że muszę albo sięgać explicite do katalogu z A (i
wymagać checkoutu A przy checkout'cie B i to w ścisłym odwzorowaniu
drzewa), albo przerabiać komuś #include'y w A, żeby przenieść x.h do
katalogu wspólnego.
Wychodzi na to, że przydałaby się jeszcze jedna, "ortogonalna"
relacja "wspólności" oprócz tworzenia branch'y.
--
Paweł Kierski
news@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Paweł Kierski - 24-12-2006 01:15
Sebastian Biały w wiadomości <eggn5t$q5l$1@uranos.cto.us.edu.pl> pisze:
> sg wrote:
> > serio? prosty plik co.bat z dwoma linijkami?
>
> Przypadek z dwoma projektami jest ... powiedzmy ... brzegowy. Aktualnie
> tego jest 5-6 sztuk. W dodatku na windowsie preferuje Tortoise do SVN.
> Więc skrypty srednipo pasują. I dalej mam pytanie, czy "zgodne" ze
> sztuką jest checkout jednego projektu w bebechy innego. Szukam
> eleganckiego rozwiązania.
>
> > ech, takie rzeczy to tylko w erze... nie da się... chyba, że zrobisz
> > sobie taki automatyczny skrypcik :)
>
> No ładnie :/ W zasadzie potrzebuje odpowiednik soft-link w repozytorium.
> Rozwiązało by mi to sporo problemów. W dokumentacji nie potrafie się
> tego doszukać.
No właśnie - też szukałem. Tym bardziej, że bywają projekty, w
których w trakcie rozwoju pliki "wspólne" w źródłach pojawiają się w
sposobó ciężki do przewidzenia. Tylko dlatego że nagle w B potrzebuję
pliku x.h powoduje, że muszę albo sięgać explicite do katalogu z A (i
wymagać checkoutu A przy checkout'cie B i to w ścisłym odwzorowaniu
drzewa), albo przerabiać komuś #include'y w A, żeby przenieść x.h do
katalogu wspólnego.
Wychodzi na to, że przydałaby się jeszcze jedna, "ortogonalna"
relacja "wspólności" oprócz tworzenia branch'y.
--
Paweł Kierski
news@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Paweł Kierski - 24-12-2006 01:15
sg w wiadomości <eggtva$d3b$1@inews.gazeta.pl> pisze:
> [...]
> bo jak to będzie większy projekt to lepiej mieć globalny
> katalog X (jeden) i niech każdy projekt sobie korzysta z tych plików.
Bywa tak, że "wspólność" plików wychodzi dużo później - ciężko
czasem przewidzieć, że jakiś kawałek źródła przyda się za kilka
miesięcy przy implementacji innego modułu. Tym bardziej, że tworząc
ten kawałek o tym nowym module nikt jeszcze nie słyszał.
--
Paweł Kierski
news@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Paweł Kierski - 24-12-2006 01:15
sg w wiadomości <eggtva$d3b$1@inews.gazeta.pl> pisze:
> [...]
> bo jak to będzie większy projekt to lepiej mieć globalny
> katalog X (jeden) i niech każdy projekt sobie korzysta z tych plików.
Bywa tak, że "wspólność" plików wychodzi dużo później - ciężko
czasem przewidzieć, że jakiś kawałek źródła przyda się za kilka
miesięcy przy implementacji innego modułu. Tym bardziej, że tworząc
ten kawałek o tym nowym module nikt jeszcze nie słyszał.
--
Paweł Kierski
news@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
sg - 24-12-2006 01:15
Paweł Kierski napisał(a):
> sg w wiadomości <eggtva$d3b$1@inews.gazeta.pl> pisze:
>> [...]
>> bo jak to będzie większy projekt to lepiej mieć globalny
>> katalog X (jeden) i niech każdy projekt sobie korzysta z tych plików.
>
> Bywa tak, że "wspólność" plików wychodzi dużo później- ciężko
> czasem przewidzieć, że jakiś kawałek źródła przyda się za kilka
> miesięcy przy implementacji innego modułu. Tym bardziej, że tworząc
> ten kawałek o tym nowym module nikt jeszcze nie słyszał.
>
to wtedy ten kawałek źródła przenoszę do jakiejś globalnej przestrzeni a
nie tylko do danego projektu A czy B
sg - 24-12-2006 01:15
Paweł Kierski napisał(a):
> sg w wiadomości <eggtva$d3b$1@inews.gazeta.pl> pisze:
>> [...]
>> bo jak to będzie większy projekt to lepiej mieć globalny
>> katalog X (jeden) i niech każdy projekt sobie korzysta z tych plików.
>
> Bywa tak, że "wspólność" plików wychodzi dużo później- ciężko
> czasem przewidzieć, że jakiś kawałek źródła przyda się za kilka
> miesięcy przy implementacji innego modułu. Tym bardziej, że tworząc
> ten kawałek o tym nowym module nikt jeszcze nie słyszał.
>
to wtedy ten kawałek źródła przenoszę do jakiejś globalnej przestrzeni a
nie tylko do danego projektu A czy B
Paweł Kierski - 24-12-2006 01:15
sg w wiadomości <egi9bf$1kv$3@inews.gazeta.pl> pisze:
[...]
> > Bywa tak, że "wspólność" plików wychodzi dużo później - ciężko
> > czasem przewidzieć, że jakiś kawałek źródła przyda się za kilka
> > miesięcy przy implementacji innego modułu. Tym bardziej, że tworząc
> > ten kawałek o tym nowym module nikt jeszcze nie słyszał.
> >
>
> to wtedy ten kawałek źródła przenoszę do jakiejś globalnej przestrzeni a
> nie tylko do danego projektu A czy B
OK - wiem, że to jest rozwiązanie, ale wymaga zmian w projekcie
"źródłowym". Po za tym przy kilku projektach w globalnej przestrzeni
robi się niezły bałagan. Z kolei próba posegregowania na zasadzie
/common/AB, /common/AC, /common/BC, /common/ABC... prowadzi do jeszcze
większego zamieszania, bo liczba takich katalogów "wspólnych" rośnie
wykładniczo. Linki w repozytorium załatwiłyby sprawę.
--
Paweł Kierski
news@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Paweł Kierski - 24-12-2006 01:15
sg w wiadomości <egi9bf$1kv$3@inews.gazeta.pl> pisze:
[...]
> > Bywa tak, że "wspólność" plików wychodzi dużo później - ciężko
> > czasem przewidzieć, że jakiś kawałek źródła przyda się za kilka
> > miesięcy przy implementacji innego modułu. Tym bardziej, że tworząc
> > ten kawałek o tym nowym module nikt jeszcze nie słyszał.
> >
>
> to wtedy ten kawałek źródła przenoszę do jakiejś globalnej przestrzeni a
> nie tylko do danego projektu A czy B
OK - wiem, że to jest rozwiązanie, ale wymaga zmian w projekcie
"źródłowym". Po za tym przy kilku projektach w globalnej przestrzeni
robi się niezły bałagan. Z kolei próba posegregowania na zasadzie
/common/AB, /common/AC, /common/BC, /common/ABC... prowadzi do jeszcze
większego zamieszania, bo liczba takich katalogów "wspólnych" rośnie
wykładniczo. Linki w repozytorium załatwiłyby sprawę.
--
Paweł Kierski
news@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
sg - 24-12-2006 01:15
Paweł Kierski napisał(a):
> sg w wiadomości <egi9bf$1kv$3@inews.gazeta.pl> pisze:
> [...]
>>> Bywa tak, że "wspólność" plików wychodzi dużo później - ciężko
>>> czasem przewidzieć, że jakiś kawałek źródła przyda sięza kilka
>>> miesięcy przy implementacji innego modułu. Tym bardziej, że tworząc
>>> ten kawałek o tym nowym module nikt jeszcze nie słyszał.
>>>
>> to wtedy ten kawałek źródła przenoszę do jakiejś globalnejprzestrzeni a
>> nie tylko do danego projektu A czy B
>
> OK - wiem, że to jest rozwiązanie, ale wymaga zmian w projekcie
> "źródłowym". Po za tym przy kilku projektach w globalnej przestrzeni
> robi się niezły bałagan. Z kolei próba posegregowania na zasadzie
> /common/AB, /common/AC, /common/BC, /common/ABC... prowadzi do jeszcze
> większego zamieszania, bo liczba takich katalogów "wspólnych" rośnie
> wykładniczo. Linki w repozytorium załatwiłyby sprawę.
>
no tak, ale na razie tego niestety nie ma, buuuuu
sg - 24-12-2006 01:15
Paweł Kierski napisał(a):
> sg w wiadomości <egi9bf$1kv$3@inews.gazeta.pl> pisze:
> [...]
>>> Bywa tak, że "wspólność" plików wychodzi dużo później - ciężko
>>> czasem przewidzieć, że jakiś kawałek źródła przyda sięza kilka
>>> miesięcy przy implementacji innego modułu. Tym bardziej, że tworząc
>>> ten kawałek o tym nowym module nikt jeszcze nie słyszał.
>>>
>> to wtedy ten kawałek źródła przenoszę do jakiejś globalnejprzestrzeni a
>> nie tylko do danego projektu A czy B
>
> OK - wiem, że to jest rozwiązanie, ale wymaga zmian w projekcie
> "źródłowym". Po za tym przy kilku projektach w globalnej przestrzeni
> robi się niezły bałagan. Z kolei próba posegregowania na zasadzie
> /common/AB, /common/AC, /common/BC, /common/ABC... prowadzi do jeszcze
> większego zamieszania, bo liczba takich katalogów "wspólnych" rośnie
> wykładniczo. Linki w repozytorium załatwiłyby sprawę.
>
no tak, ale na razie tego niestety nie ma, buuuuu
Sebastian Bialy - 24-12-2006 01:15
Sebastian Biały wrote:
> [ciach]
Napiszę nieco więcej o problemie, bo może znajdzie się inne rozwiązanie
niż SVN.
Konkretnie: mam projekty różne nazwane A,B,C,D,...
Większość z nich jest kierowana na CPU z mikroskopijnymi ilościami
RAM/ROM. Zmuszony jestem kompilować kod tak, aby zminimalizaować jego
długość i pamięciożernośc.
Wszystkie projekty korzystają ze wspólnego kawałka kodu X.
Niestety kod X w zależoności od architektury/zasobów sprzętowych/etc za
każdym razem może wyglądać całkiem inaczej. Z powodów o których mówiłem
steruje jego wynikiem za pomocą definicji kompilatora z każdego projektu
inaczej. Np: raz X używa UARTa sprzętowego, niekiedy go emuluje, a
czasami w ogóle nie ma.
Problem:
Aby usunąć kod X na zewnątrz projektów do biblioteki musiałbym
przewidzieć każdą możliwą kombinację definicji sterujących jego budową i
wyprodukowac obiekty. W dodatku nie każda kombinacja jest możliwa/ma sens.
Każdy projekt A,B,C definiuje swoje potrzeby z użyciem jakiś definicji i
pod jego potrzeby generowany jest kod z X. Jesli X zawiera się w A,B,C
to sprawa jest prosta i oczywista. Jeśli jest poza - nie widze
możliwości jego generowania niezależnie od A,B,C (a nawet jesli to
nieoptymalnie i niewygodnie).
Od razu mówie, że stosowanie w moim przypadku wymyślnych wzorców
projektowych w tym samym celu w ogóle się nie sprawdzi - ja walcze o
pojedyncze bajty i jedyną możliwością jest #ifdef [...] #endif. Nawet
podział X na obiekty nie ma sensu, bo i tak musze pojedyncze skłądniki
kompilować wielokrotnie dla różnych prędkości kwarców stosowanych w A,B,C,D.
Może jednak istnieje jakieś rozwiązanie inne niż pomysł z repozytorium i
linkami wewnątrz?
Sebastian Bialy - 24-12-2006 01:15
Sebastian Biały wrote:
> [ciach]
Napiszę nieco więcej o problemie, bo może znajdzie się inne rozwiązanie
niż SVN.
Konkretnie: mam projekty różne nazwane A,B,C,D,...
Większość z nich jest kierowana na CPU z mikroskopijnymi ilościami
RAM/ROM. Zmuszony jestem kompilować kod tak, aby zminimalizaować jego
długość i pamięciożernośc.
Wszystkie projekty korzystają ze wspólnego kawałka kodu X.
Niestety kod X w zależoności od architektury/zasobów sprzętowych/etc za
każdym razem może wyglądać całkiem inaczej. Z powodów o których mówiłem
steruje jego wynikiem za pomocą definicji kompilatora z każdego projektu
inaczej. Np: raz X używa UARTa sprzętowego, niekiedy go emuluje, a
czasami w ogóle nie ma.
Problem:
Aby usunąć kod X na zewnątrz projektów do biblioteki musiałbym
przewidzieć każdą możliwą kombinację definicji sterujących jego budową i
wyprodukowac obiekty. W dodatku nie każda kombinacja jest możliwa/ma sens.
Każdy projekt A,B,C definiuje swoje potrzeby z użyciem jakiś definicji i
pod jego potrzeby generowany jest kod z X. Jesli X zawiera się w A,B,C
to sprawa jest prosta i oczywista. Jeśli jest poza - nie widze
możliwości jego generowania niezależnie od A,B,C (a nawet jesli to
nieoptymalnie i niewygodnie).
Od razu mówie, że stosowanie w moim przypadku wymyślnych wzorców
projektowych w tym samym celu w ogóle się nie sprawdzi - ja walcze o
pojedyncze bajty i jedyną możliwością jest #ifdef [...] #endif. Nawet
podział X na obiekty nie ma sensu, bo i tak musze pojedyncze skłądniki
kompilować wielokrotnie dla różnych prędkości kwarców stosowanych w A,B,C,D.
Może jednak istnieje jakieś rozwiązanie inne niż pomysł z repozytorium i
linkami wewnątrz?
Piotr Dembiński - 24-12-2006 01:15
Sebastian Biały <heby@poczta.onet.pl> writes:
[...]
> czy "zgodne" ze sztuką jest checkout jednego projektu w bebechy
> innego. Szukam eleganckiego rozwiązania.
Jeśli potrafisz projektować/programować, to najlepiej chyba
potraktować infrastrukturę w ramach której pisze się program jako
pewien system informatyczny i zaprojekotwać/przeprojektować ten system
tak, jak każdy inny.
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński - 24-12-2006 01:15
Sebastian Biały <heby@poczta.onet.pl> writes:
[...]
> czy "zgodne" ze sztuką jest checkout jednego projektu w bebechy
> innego. Szukam eleganckiego rozwiązania.
Jeśli potrafisz projektować/programować, to najlepiej chyba
potraktować infrastrukturę w ramach której pisze się program jako
pewien system informatyczny i zaprojekotwać/przeprojektować ten system
tak, jak każdy inny.
--
http://www.piotr.dembiński.prv.pl
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
kilka obrazków składa się na jeden widok
skladanie zdjecia ze zdjec
Najlepsze praktyki projketowania graficznego interfejsu z użytkownikiem
[mysql] Drobny problem z UPPER()
ms sql i spacje na koncu danych
Problem z materiałem Light Block
oracle developer suite - problemy
Szukam skryptu GPTR - do wysylania platnych E-maili
mysql dodawanie nowych wierszy
FB i użytkownicy XP Home
zanotowane.pldoc.pisz.plpdf.pisz.pldirtyboys.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
