Hi,
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 =
list=20
in a case of any commits:
In the loginfo file of the CVS Repository=20
DEFAULT $CVSROOT/CVSROOT/log -m uml-devel@... -s \
-f /dev/null
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=
e
> > 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=
o
> 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=
he
> next 4 weeks I've been sending all my code to paul so that he could put=
it
> into cvs, but I dont remember seeing any mail telling someone has modif=
ied
> some code, so I have no idea what the status of the cvs code is right n=
ow.
>
So I understand we can get write access to the SF cvs in a simple way. Pa=
ul=20
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=
ets
> 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=
lves
> to notify on the list the changes they make / apply. That why we all kn=
ow
> what to expect when downloading cvs.
>
> paul: you said you wanted to pass on project coordination. is this stil=
l
> 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=
ame
> uml-luis2.tar.bzw) that file fixed the line terminator problems, fixed =
the
> code generator problems and added a couple of new features (Esc and Shi=
ft)
> ) 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=
e=20
cvs. A better way is, to define some TAGS and open some branches for test=
=20
versions outside the mainstream (like in the linux kernel). These branche=
s=20
have nothing to do with branches due to releases. The "owner" of such bra=
nch=20
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=
y
> from it.
If you work in this way you have problems with testing. Lets work in that=
way=20
that a lot of people may test your newest code. You have only to ensure t=
hat=20
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=
ere=20
no changes made by other developers commit your changes. Otherwise you ha=
ve=20
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=
=20
last procedure rarely. Mostly you did not find a lot of changes before yo=
u=20
try to commit.
From my point of view the maintainer or coordinator should decide wether =
the=20
state may released or not (of course with the help of the other developer=
s)
> 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=
es
> the same (send it to the coordinator)
> the coordinator tests that everything is working (should build and inst=
all
> without any problems) if this is the case, he makes a distclean, remove=
s
> 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=
st
> (should not take too long to write a two lines email) and take care not=
to
> add files which should not be in cvs, like Makefiles and the such. Thos=
e
> 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=
o
> much time, so it will probably mean to suspend things for a couple of d=
ays,
> but I think it's worth it.
> I dont think I can do it because I dont have cvs / internet access at h=
ome,
> but if no one else can /wants, you can send me your files per email, I'=
ll
> 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=
ou
> can do it? Paul?
>
> regards,
>
> Luis
Regards=20
Jens
--=20
Jens Kr=C3=BCger
Technische Universit=C3=A4t M=C3=BCnchen
ZWE FRM-II
Lichtenberg-Str. 1
D-85747 Garching
Tel: + 49 89 289 14 716
Fax: + 49 89 289 14 666
mailto:jens_krueger@...
http://www.frm2.tu-muenchen.de
|