[GRASS5] question about CVS

GRASS GIS GRASS GIS developer
1

I am hoping that someone can check the CVS for me and give an independent
opinion on something that doesn¹t look quite right from my end.

I updated menu.tcl for d.m this morning and tried to update the script
r.univar.sh so that it gets compiled by default. I successfully updated the
script itself and associated description and html files. The latter was
necessary as it was getting compiled as r.univar, confusing with the binary
module r.univar. I also made a small update to the script. So far so good.

However, when I tried to change the name of the script directory from
r.univar to r.univar.sh it APPEARED to commit properly, but it seems to be
unchanged (i.e., still /r.univar) when I look at it via the web based CVS
page (a way to check to see if my commits have Œtaken¹). Also, when I try to
update the scripts Makefile accordingly, changing the entry from r.univar/
to r.univar.sh/ I am getting an error and it won¹t commit.

Possibly related, when I did the overhaul of d.m earlier this week, I also
committed a script directory, within the d.m folder. However, it doesn¹t
look as though it is there when I look at it via the web based CVS page.

Could someone check to see whether

1. the /scripts/r.univar directory has been changed to /scripts r.univar.sh?
2. if the scripts Makefile has been updated, changing r.univar / to
r.univar.sh /
3. If the /display/d.m/script directory is there

Thanks
Michael
______________________________
Michael Barton, Professor & Curator
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

Hello Michael

You can't rename or delete a directory in CVS (well Bernhard may be able to do it by directly editing the repository but other developers with CVS write access cannot, and I think it is good practice not to try to as it does not show up in the CVS logs then). All you can do is delete all the files in it and create a new directory with the name you wanted to rename it to.

I don't think it's necessary in this case though---renaming r.univar to r.univar.sh in the Makefiles etc. as has been done should be sufficient. Scripts don't get compiled, simply copied over into the appropriate place in the dist.$ARCH directory. Perhaps there is an old copy of r.univar that needs deleted there?

On your other point about the d.m/script directory: you can't create a directory as part of a CVS commit operation. A new directly has to be added separately as a preliminary step and the change takes effect immediately in the CVS repository (i.e. without issuing a cvs commit command). As it's also impossible to delete a directory I think this behaviour is kind of strange but it seems to be the way CVS works---unless I've missed something.

I can't remember the CVS command to create a new directory but you can look it up in the man page. Probably cvs mkdir or something like that.
After that you must 'cvs add' the files in the new directory before the commit but probably you know that...

Hope this helps a bit

Paul

On Thu, 16 Sep 2004, Michael Barton wrote:

I am hoping that someone can check the CVS for me and give an independent
opinion on something that doesn¹t look quite right from my end.

I updated menu.tcl for d.m this morning and tried to update the script
r.univar.sh so that it gets compiled by default. I successfully updated the
script itself and associated description and html files. The latter was
necessary as it was getting compiled as r.univar, confusing with the binary
module r.univar. I also made a small update to the script. So far so good.

However, when I tried to change the name of the script directory from
r.univar to r.univar.sh it APPEARED to commit properly, but it seems to be
unchanged (i.e., still /r.univar) when I look at it via the web based CVS
page (a way to check to see if my commits have Œtaken¹). Also, when I try to
update the scripts Makefile accordingly, changing the entry from r.univar/
to r.univar.sh/ I am getting an error and it won¹t commit.

Possibly related, when I did the overhaul of d.m earlier this week, I also
committed a script directory, within the d.m folder. However, it doesn¹t
look as though it is there when I look at it via the web based CVS page.

Could someone check to see whether

1. the /scripts/r.univar directory has been changed to /scripts r.univar.sh?
2. if the scripts Makefile has been updated, changing r.univar / to
r.univar.sh /
3. If the /display/d.m/script directory is there

Thanks
Michael
______________________________
Michael Barton, Professor & Curator
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

Michael Barton wrote:

I am hoping that someone can check the CVS for me and give an independent
opinion on something that doesn¹t look quite right from my end.

I updated menu.tcl for d.m this morning and tried to update the script
r.univar.sh so that it gets compiled by default. I successfully updated the
script itself and associated description and html files. The latter was
necessary as it was getting compiled as r.univar, confusing with the binary
module r.univar. I also made a small update to the script. So far so good.

However, when I tried to change the name of the script directory from
r.univar to r.univar.sh it APPEARED to commit properly, but it seems to be
unchanged (i.e., still /r.univar) when I look at it via the web based CVS
page (a way to check to see if my commits have Œtaken¹). Also, when I try to
update the scripts Makefile accordingly, changing the entry from r.univar/
to r.univar.sh/ I am getting an error and it won¹t commit.

There isn't any need to rename the directory. Which is good, because
CVS doesn't allow renaming directories; you have to "cvs remove" all
of the files from the old directory, "cvs add" the new directory and
all of the files which it contains, then "cvs commit" both. And by
doing this, you lose the history.

Possibly related, when I did the overhaul of d.m earlier this week, I also
committed a script directory, within the d.m folder. However, it doesn¹t
look as though it is there when I look at it via the web based CVS page.

Could someone check to see whether

1. the /scripts/r.univar directory has been changed to /scripts
r.univar.sh?

No.

2. if the scripts Makefile has been updated, changing r.univar / to
r.univar.sh /

No.

3. If the /display/d.m/script directory is there

No.

For point 3, you need to do something like:

  cvs add display/d.m/script
  cd display/d.m/script
  cvs add *.*
  cvs commit

I'd suggest leaving r.univar alone; simply adding r.univar to
scripts/Makefile should have been sufficient.

--
Glynn Clements <glynn.clements@virgin.net>

4

r.univar.sh should be ok as is. As Paul noted, you can't rename stuff
(only add new and remove old) but you don't need to. Module name is
generally specified in the Makefile (scripts need renaming too).
You need to 'cvs add directory' ..

there is a problem with the last commit:
grass51/scripts/r.univar/r.univar.sh
Revision 1.3, Thu Sep 16 15:54:55 2004 UTC by michael

It reverted a fix by Glynn from 6 days ago. (hardcoded path)
Always run 'cvs update filename' to update to the latest before doing
modifications and 'cvs diff filename' to check changes before
committing. Viewing it on the web interface afterwards is a good check
too.

These non-intuitive quirks is why a lot of people like Subversion better
(but then it has its own quirks and bugs).

Hamish

I am hoping that someone can check the CVS for me and give an
independent opinion on something that doesn¹t look quite right from my
end.

I updated menu.tcl for d.m this morning and tried to update the script
r.univar.sh so that it gets compiled by default. I successfully
updated the script itself and associated description and html files.
The latter was necessary as it was getting compiled as r.univar,
confusing with the binary module r.univar. I also made a small update
to the script. So far so good.

However, when I tried to change the name of the script directory from
r.univar to r.univar.sh it APPEARED to commit properly, but it seems
to be unchanged (i.e., still /r.univar) when I look at it via the web
based CVS page (a way to check to see if my commits have _taken¹).
Also, when I try to update the scripts Makefile accordingly, changing
the entry from r.univar/ to r.univar.sh/ I am getting an error and it
won¹t commit.

Possibly related, when I did the overhaul of d.m earlier this week, I
also committed a script directory, within the d.m folder. However, it
doesn¹t look as though it is there when I look at it via the web based
CVS page.

Could someone check to see whether

1. the /scripts/r.univar directory has been changed to /scripts
r.univar.sh? 2. if the scripts Makefile has been updated, changing
r.univar / to r.univar.sh /
3. If the /display/d.m/script directory is there

5

On Thu, Sep 16, 2004 at 08:51:41PM +0100, Paul Kelly wrote:

You can't rename or delete a directory in CVS (well Bernhard may be able
to do it by directly editing the repository but other developers with CVS
write access cannot, and I think it is good practice not to try to as it
does not show up in the CVS logs then). All you can do is delete all the
files in it and create a new directory with the name you wanted to rename
it to.

That is true:
In rare cases I can rename directly on the repository,
but I would need to stop access for a while then.
History is preserved to some extend if I just "move" a file or directory.

6

On Fri, Sep 17, 2004 at 04:35:32PM +1200, Hamish wrote:

These non-intuitive quirks is why a lot of people like Subversion better
(but then it has its own quirks and bugs).

Subversion is pretty new among revision control systems.
This is the main reason why it was not considered when we set
up a repository for CVS.
Today I probably would try monotone or subversion.
Currently CVS does its job fine, so if I had more time to hack on
GRASS I would not choose to plan a migration to subversion, because
the value to gain is low.