Am Freitag, 19. Juli 2002 09:46 schrieb Luis De la Parra:
There is a simple way to setup the CVS to send a message to the um-devel =
in a case of any commits:
In the loginfo file of the CVS Repository=20
DEFAULT $CVSROOT/CVSROOT/log -m uml-devel@... -s \
and in the notify file
ALL mail %s -s "CVS notification"
now all commits should create a mail to the mailing list.
Our CVS runs with this set-up.
> > How do you guys announce changes on the CVS tree anyway? Is there som=
> > automatism or do you do it manually here on the list? Just curious.
Luis you are right.
> I think we are having a serious organizational problem here. It seems n=
> one knows who is doing what, and cvs is really a mess.
> Since I cant write to cvs and wont have internet access from home for t=
> next 4 weeks I've been sending all my code to paul so that he could put=
> into cvs, but I dont remember seeing any mail telling someone has modif=
> some code, so I have no idea what the status of the cvs code is right n=
So I understand we can get write access to the SF cvs in a simple way. Pa=
has to set up the CVS in that way, you get write access.
> is there a way to set SF to notify to the list automatically when cvs g=
> updated? (paul??) if yes, we need to turn it on. if no, it'd be nice to
> know who has write access to cvs, and those people should commit themse=
> to notify on the list the changes they make / apply. That why we all kn=
> what to expect when downloading cvs.
> paul: you said you wanted to pass on project coordination. is this stil=
> the case? who is now guiding uml?
> I still have my copy of cvs which I sent to paul a few days ago (file n=
> uml-luis2.tar.bzw) that file fixed the line terminator problems, fixed =
> code generator problems and added a couple of new features (Esc and Shi=
> ) but I dont really know if that code ever made it to CVS or if Paul's
> crash happened before that.
Why do you want to block the cvs? I think it is not necessary to block th=
cvs. A better way is, to define some TAGS and open some branches for test=
versions outside the mainstream (like in the linux kernel). These branche=
have nothing to do with branches due to releases. The "owner" of such bra=
should take care for the merging from the mainstream and vice versa.
> Anyways.. I know it sounds like a lot of work, but I think this is what
> should happen:
> The "coordinator" should temporarly block cvs, and then get a fresh cop=
> from it.
If you work in this way you have problems with testing. Lets work in that=
that a lot of people may test your newest code. You have only to ensure t=
your code is compiling. My opinions from the work show that it works fine.
The requirement for this kind of work is:
update your current working space with the content of the CVS. If there w=
no changes made by other developers commit your changes. Otherwise you ha=
to test the code again and to repeat the procedure until no changes were=20
found. It sounds a little bit strange, but in practice you have to do the=
last procedure rarely. Mostly you did not find a lot of changes before yo=
try to commit.
From my point of view the maintainer or coordinator should decide wether =
state may released or not (of course with the help of the other developer=
> I can send him my file and he can compare / merge the files.
> Anyone else who has done some code and is not sure it made it to cvs do=
> the same (send it to the coordinator)
> the coordinator tests that everything is working (should build and inst=
> without any problems) if this is the case, he makes a distclean, remove=
> Makefile.in, configure, and all other files that are automatically
> generated and then cleans cvs (copy the whole repository to a back up
> place) and does a new, fresh import with the fixed code.
> From this point on, people writing to cvs must notify changes to the li=
> (should not take too long to write a two lines email) and take care not=
> add files which should not be in cvs, like Makefiles and the such. Thos=
> should be generated locally and shold stay local.
> what to do you think? who is going to do it? I know we all dont have to=
> much time, so it will probably mean to suspend things for a couple of d=
> but I think it's worth it.
> I dont think I can do it because I dont have cvs / internet access at h=
> but if no one else can /wants, you can send me your files per email, I'=
> put them together and then send it to someone with cvs access who would
> only need to backup cvs, delete everything and make a fresh import.
> There was a volunteer to take over project coordination. Do you think y=
> can do it? Paul?
Technische Universit=C3=A4t M=C3=BCnchen
Tel: + 49 89 289 14 716
Fax: + 49 89 289 14 666