Hi,
Since the interactive g.region has been removed from GRASS 6,
general/g.region has only Makefile and cmd directory. Do we need to
keep this redundant directory?
Huidae
Huidae Cho wrote:
Since the interactive g.region has been removed from GRASS 6,
general/g.region has only Makefile and cmd directory. Do we need to
keep this redundant directory?
I suggest not.
The only reason to keep the directory is to preserve CVS history. To
"move" files in CVS, you remove the old file and add the file in its
new location. The new file starts at version 1.1, with no history. You
can still get the history for the original file, but that has to be
done separately, and you have to know the old name (it's a good idea
to add this information in the commit message for the new file).
You can move files within the repository, but that breaks checking out
older versions, as CVS will think that the file has always been at its
new location.
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, Oct 24, 2006 at 09:44:08PM +0100, Glynn Clements wrote:
Huidae Cho wrote:
> Since the interactive g.region has been removed from GRASS 6,
> general/g.region has only Makefile and cmd directory. Do we need to
> keep this redundant directory?I suggest not.
The only reason to keep the directory is to preserve CVS history. To
"move" files in CVS, you remove the old file and add the file in its
new location. The new file starts at version 1.1, with no history. You
can still get the history for the original file, but that has to be
done separately, and you have to know the old name (it's a good idea
to add this information in the commit message for the new file).You can move files within the repository, but that breaks checking out
older versions, as CVS will think that the file has always been at its
new location.
Could an internal link in the CVS help to solve this issue?
Ugly, but here we only speak about ../
?
Markus
HC:
> > Since the interactive g.region has been removed from GRASS 6,
> > general/g.region has only Makefile and cmd directory. Do we need
> > to keep this redundant directory?
GC:
> I suggest not.
>
> The only reason to keep the directory is to preserve CVS history. To
> "move" files in CVS, you remove the old file and add the file in its
> new location. The new file starts at version 1.1, with no history.
> You can still get the history for the original file, but that has to
> be done separately, and you have to know the old name (it's a good
> idea to add this information in the commit message for the new
> file).
>
> You can move files within the repository, but that breaks checking
> out older versions, as CVS will think that the file has always been
> at its new location.
MN:
Could an internal link in the CVS help to solve this issue?
Ugly, but here we only speak about ../
before we start introducing ugly hacks into the CVS, it might be good to
know if this sort of thing would be much easier to do cleanly in SVN. If
so, I suggest we wait until (if?) we migrate the CVS+history to that.
Hamish
Markus Neteler wrote:
> > Since the interactive g.region has been removed from GRASS 6,
> > general/g.region has only Makefile and cmd directory. Do we need to
> > keep this redundant directory?
>
> I suggest not.
>
> The only reason to keep the directory is to preserve CVS history. To
> "move" files in CVS, you remove the old file and add the file in its
> new location. The new file starts at version 1.1, with no history. You
> can still get the history for the original file, but that has to be
> done separately, and you have to know the old name (it's a good idea
> to add this information in the commit message for the new file).
>
> You can move files within the repository, but that breaks checking out
> older versions, as CVS will think that the file has always been at its
> new location.Could an internal link in the CVS help to solve this issue?
Ugly, but here we only speak about ../
A link would make CVS think that it has always been in both locations.
The interruption to the history caused by remove+add is almost always
the least bad option.
--
Glynn Clements <glynn@gclements.plus.com>