явно няма да ми помогнете, а ще ми прочетете лекция кое как е правилно.
ситуацията е такава защото е такава :-) и в този момент промяна е
невъзможна.
commit-ването на CVS-a задейства няколко скрипта, които правят няколко други
неща, по няколко други сервера свързани с работата на системата и затова се
комитва на всеки запис на скриптовете.едва ли е мястото тук да обяснявам за
какво точно се ползва този CVS, а и не е необходимо. ситуацията не е
стандартна затова попитах за идеи. стандартния начин кое как се прави и баба
го знае :-) ,а ако не го знае има доста изписано по въпроса в интернет ;-).
айде да не флудим повече, моля да пише само този, които има реално
предложение за конкретната ситуация.
г.
On 7/27/07, milen nikolov [EMAIL PROTECTED] wrote:
On Fri, 2007-07-27 at 14:28 +0300, Vasil Kolev wrote:
В пт, 2007-07-27 в 14:02 +0300, milen nikolov написа:
On Fri, 2007-07-27 at 10:49 +0300, Gggg ggg wrote:
не е точно така.докато се пише код общо взето се записва и тества
резултата на сървъра по средно 2-3 пъти в минута.
не е това идеята като се ползва CVS
основната идята да се ползва CVS при разработка е да се пазят версии и
да се разрешават конфликти при работа на няколко програмисти по един
проект. безмислено е да се комитва през 2-3 минути, да не кажа тъпо.
Програмистите ти трябва да си ъплоадват сами към вебсървъра и когато
напишат значима част от проекта, тогава да комитват, или да комитват
примерно в края на работния ден.
Това са глупости. Какво пречи на програмистите през svn-а да качват
новите неща на сървъра, commit при тях, update на сървъра? Така после
можеш лесно да update-неш навсякъде.
е нали и аз това казах, може не съм се изразил ясно.
Другото нещо е, че се commit-ват промени, които са смислени (ако не
тестваш) - не един път на края на деня, дето си написал 30 различни
неща, а всяко по отделно, за да има смисъл от нещата, които си качил.
Дневното commit-ване е в общи линии за backup, отколкото за нещо
полезно.
това имах предвид
Иначе да тестваш 3 пъти в минута си е бая сложно упражнение, та ми се
вижда малко преувеличено това на G :)
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg
--
Milen Trifonov
Sirma Solutions
System Administrator
e-mail: [EMAIL PROTECTED]
---
The problem that we thought was a problem was, indeed,
a problem, but not the problem we thought was the problem.
-- Mike Smith
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg
