IMPORTANT: DO NOT RUN "cvs update".
I just tried a "cvs update", and it very much looks as if the CVS
repository has suffered a botched merge attempt. I *really* hope that
someone has a backup.
--
Glynn Clements <glynn.clements@virgin.net>
If there are no better solutions then I have the the entire tagged release
that I downloaded and updated about 4 1/2 hours ago. I've made no changes.
Roger Miller
On Thu, 9 Aug 2001, Glynn Clements wrote:
IMPORTANT: DO NOT RUN "cvs update".
I just tried a "cvs update", and it very much looks as if the CVS
repository has suffered a botched merge attempt. I *really* hope that
someone has a backup.--
Glynn Clements <glynn.clements@virgin.net>
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Roger Miller wrote:
> I just tried a "cvs update", and it very much looks as if the CVS
> repository has suffered a botched merge attempt. I *really* hope that
> someone has a backup.If there are no better solutions then I have the the entire tagged release
that I downloaded and updated about 4 1/2 hours ago. I've made no changes.
I meant a backup of the repository itself; I reverted my local copy
with "cvs update -r ... -D ...".
But the repository itself would ideally be restored to the state it
was in before the snafu. Otherwise there's going to be a pretty
massive artifact in the revision history. Unfortunately CVS doesn't
have a "rollback" command.
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, Aug 09, 2001 at 11:31:54PM +0100, Glynn Clements wrote:
> > repository has suffered a botched merge attempt. I *really* hope that
> > someone has a backup.
>
> If there are no better solutions then I have the the entire tagged release
> that I downloaded and updated about 4 1/2 hours ago. I've made no changes.I meant a backup of the repository itself; I reverted my local copy
with "cvs update -r ... -D ...".But the repository itself would ideally be restored to the state it
was in before the snafu. Otherwise there's going to be a pretty
massive artifact in the revision history. Unfortunately CVS doesn't
have a "rollback" command.
before we'll have a look at the trouble, just a comment:
The CVS repository is mirrored each night to another
computer (in some kilometers distance from the main server,
so that even a fire or something like that can not destroy
original and backups at the same time).
Furthermore every evening the whole stuff is written to a tape.
Since we don't reuse tapes, there is a large quantity now
that ranges back to the beginning of the GRASS CVS
allowing to retrieve a repository for almost any date.
Hope you can sleep better now 
Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
On Thu, Aug 09, 2001 at 11:31:54PM +0100, Glynn Clements wrote:
Roger Miller wrote:
> > I just tried a "cvs update", and it very much looks as if the CVS
> > repository has suffered a botched merge attempt. I *really* hope that
> > someone has a backup.
>
> If there are no better solutions then I have the the entire tagged release
> that I downloaded and updated about 4 1/2 hours ago. I've made no changes.I meant a backup of the repository itself; I reverted my local copy
with "cvs update -r ... -D ...".But the repository itself would ideally be restored to the state it
was in before the snafu. Otherwise there's going to be a pretty
massive artifact in the revision history. Unfortunately CVS doesn't
have a "rollback" command.
As Jan pointed out we do have a backup.
On the other hand we should try to work out the problems
using CVS first before trying the backup (IMO).
Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
Hi,
what is the current status of CVS? An update some minutes ago
brought some file back. My latest change to r.fillnull from
August 8th seems to be present, even the latest changes
to html/
Carefully I would say, the CVS is back o.k.
What has happened here???
Confused (I was always trusting our CVS),
Markus
On Fri, Aug 10, 2001 at 11:25:37AM +0200, Markus Neteler wrote:
Hi,
what is the current status of CVS? An update some minutes ago
brought some file back. My latest change to r.fillnull from
August 8th seems to be present, even the latest changes
to html/Carefully I would say, the CVS is back o.k.
What has happened here???
Confused (I was always trusting our CVS),
The CVS is fine and was always running fine.
Probably Glynn experienced what they would call "cvs abnormality"
in star-trek.
Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
On Fri, Aug 10, 2001 at 11:31:16AM +0200, Bernhard Reiter wrote:
On Fri, Aug 10, 2001 at 11:25:37AM +0200, Markus Neteler wrote:
> Hi,
>
> what is the current status of CVS? An update some minutes ago
> brought some file back. My latest change to r.fillnull from
> August 8th seems to be present, even the latest changes
> to html/
>
> Carefully I would say, the CVS is back o.k.
>
> What has happened here???
>
> Confused (I was always trusting our CVS),The CVS is fine and was always running fine.
Probably Glynn experienced what they would call "cvs abnormality"
in star-trek.
Actually the "cvs abnormality" must have been worldwide as I
also received tons of changes (which are now updated again).
Therefore I have build a new CVS snapshot which get's mirrored
this night.
Markus
Bernhard Reiter wrote:
> > > I just tried a "cvs update", and it very much looks as if the CVS
> > > repository has suffered a botched merge attempt. I *really* hope that
> > > someone has a backup.
> >
> > If there are no better solutions then I have the the entire tagged release
> > that I downloaded and updated about 4 1/2 hours ago. I've made no changes.
>
> I meant a backup of the repository itself; I reverted my local copy
> with "cvs update -r ... -D ...".
>
> But the repository itself would ideally be restored to the state it
> was in before the snafu. Otherwise there's going to be a pretty
> massive artifact in the revision history. Unfortunately CVS doesn't
> have a "rollback" command.As Jan pointed out we do have a backup.
On the other hand we should try to work out the problems
using CVS first before trying the backup (IMO).
The problem with attempting to fix it using CVS is the lack of a
"rollback" option. You can check-out an older version then re-commit
it, but the aberration persists in the revision history for all time.
Basically, the only way to make CVS "forget" something is to either
restore the repository from a backup, or modify the repository
directly (and I definitely wouldn't recommend the latter option).
This can be a serious problem if someone commits something which is
legally problematic, e.g. code which infringes patents or copyrights,
contains defamatory comments etc.
In this case, it's just a nuisance.
--
Glynn Clements <glynn.clements@virgin.net>
Markus Neteler wrote:
what is the current status of CVS? An update some minutes ago
brought some file back. My latest change to r.fillnull from
August 8th seems to be present, even the latest changes
to html/Carefully I would say, the CVS is back o.k.
It isn't.
What has happened here???
An example:
On 2001/04/29, I replaced d.rgb with a version which used RGB raster
operations (D_draw_raster_RGB), comprising:
src/display/d.rgb/Gmakefile
src/display/d.rgb/main.c
These files are still there, and src/display/d.rgb/CVS/Tag contains:
Treleasebranch_11_april_2001_5_0_0
However, the most recent update adds the old version of d.rgb in
src/display/d.rgb/cmd, with src/display/d.rgb/cmd/CVS/Tag containing:
Nreleasebranch_11_april_2001_5_0_0
Note: "T" indicates a branch tag, "N" indicates a non-branch tag.
AFAICT, any other files which had been removed from the release branch
have re-appeared in the latest version.
I haven't seen any cases where existing files have been replaced by
the wrong version, but the presence of additional files could still
interfere with the build process, e.g. adding subdirectories to any
directory whose Gmakefile uses $(MAKEALL), or adding header files
which conflict with header files occurring later in the include path.
As I mentioned earlier, use of -D allowed me to get a pre-snafu
version of the source tree, but there isn't much point in committing
anything while the problem remains.
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, Aug 10, 2001 at 01:01:58PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> what is the current status of CVS? An update some minutes ago
> brought some file back. My latest change to r.fillnull from
> August 8th seems to be present, even the latest changes
> to html/
>
> Carefully I would say, the CVS is back o.k.It isn't.
> What has happened here???
An example:
On 2001/04/29, I replaced d.rgb with a version which used RGB raster
operations (D_draw_raster_RGB), comprising:src/display/d.rgb/Gmakefile
src/display/d.rgb/main.cThese files are still there, and src/display/d.rgb/CVS/Tag contains:
Treleasebranch_11_april_2001_5_0_0
However, the most recent update adds the old version of d.rgb in
src/display/d.rgb/cmd, with src/display/d.rgb/cmd/CVS/Tag containing:Nreleasebranch_11_april_2001_5_0_0
Note: "T" indicates a branch tag, "N" indicates a non-branch tag.
AFAICT, any other files which had been removed from the release branch
have re-appeared in the latest version.I haven't seen any cases where existing files have been replaced by
the wrong version, but the presence of additional files could still
interfere with the build process, e.g. adding subdirectories to any
directory whose Gmakefile uses $(MAKEALL), or adding header files
which conflict with header files occurring later in the include path.As I mentioned earlier, use of -D allowed me to get a pre-snafu
version of the source tree, but there isn't much point in committing
anything while the problem remains.
In this case I vote for an immediate write-lock of CVS.
Too bad!!
Markus
On Fri, Aug 10, 2001 at 12:23:38PM +0100, Glynn Clements wrote:
Basically, the only way to make CVS "forget" something is to either
restore the repository from a backup, or modify the repository
directly (and I definitely wouldn't recommend the latter option).
Changes directly in the repository are the way to go in
such cases (it is even mentioned in documentation/manuals).
Some maintenance operations only could be done this way.
Of course, doing so means you must be extemely careful.
Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
On Fri, Aug 10, 2001 at 02:10:51PM +0200, Markus Neteler wrote:
On Fri, Aug 10, 2001 at 01:01:58PM +0100, Glynn Clements wrote:
> It isn't.
> An example:
>
> On 2001/04/29, I replaced d.rgb with a version which used RGB raster
> operations (D_draw_raster_RGB), comprising:
>
> src/display/d.rgb/Gmakefile
> src/display/d.rgb/main.c
>
> These files are still there, and src/display/d.rgb/CVS/Tag contains:
>
> Treleasebranch_11_april_2001_5_0_0
>
> However, the most recent update adds the old version of d.rgb in
> src/display/d.rgb/cmd, with src/display/d.rgb/cmd/CVS/Tag containing:
>
> Nreleasebranch_11_april_2001_5_0_0
>
> Note: "T" indicates a branch tag, "N" indicates a non-branch tag.
>
> AFAICT, any other files which had been removed from the release branch
> have re-appeared in the latest version.
>
> I haven't seen any cases where existing files have been replaced by
> the wrong version, but the presence of additional files could still
> interfere with the build process, e.g. adding subdirectories to any
> directory whose Gmakefile uses $(MAKEALL), or adding header files
> which conflict with header files occurring later in the include path.
>
> As I mentioned earlier, use of -D allowed me to get a pre-snafu
> version of the source tree, but there isn't much point in committing
> anything while the problem remains.In this case I vote for an immediate write-lock of CVS.
Too bad!!
We have to analyse the problem then first.
I do not have time immedealty, so we every developer should
stop commiting unless the problem is clear
and we know how to procede.
There is no easy method to stop people from committing,
witout disabling cvs-ssh access completly.
Glynn: Can you start investigating what was going on?
Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
Bernhard Reiter wrote:
Glynn: Can you start investigating what was going on?
It, would be preferable if someone else could do it, as:
1. I don't have access (AFAIK) to the administrative files
(CVSROOT/history, and all the ",v" files), or to a backup against
which to compare them. Both of these would be useful.
2. I'm on a 56kbps (if I'm lucky) link (with per-minute charges). So a
brute force "cvs checkout" and "cvs log" of all of the potentially
interesting snapshots will be slow and expensive. And may not actually
help anyway.
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, Aug 10, 2001 at 09:58:26PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> Glynn: Can you start investigating what was going on?
It, would be preferable if someone else could do it, as:
1. I don't have access (AFAIK) to the administrative files
(CVSROOT/history, and all the ",v" files), or to a backup against
which to compare them. Both of these would be useful.2. I'm on a 56kbps (if I'm lucky) link (with per-minute charges). So a
brute force "cvs checkout" and "cvs log" of all of the potentially
interesting snapshots will be slow and expensive. And may not actually
help anyway.
Hi,
I just have prepared a Changelog file at:
http://grass.itc.it/test/ChangeLog.gz
I would be glad if everybody could check for latest changes
eventually missing.
Thanks,
Markus
Glynn Clements wrote:
As I mentioned earlier, use of -D allowed me to get a pre-snafu
version of the source tree, but there isn't much point in committing
anything while the problem remains.
Here's another interesting point:
cvs update -r releasebranch_11_april_2001_5_0_0 src/display/d.rgb
retrieves the bogus files, but
cvs update -r releasebranch_11_april_2001_5_0_0 -D '2001-08-13 16:00' src/display/d.rgb
doesn't (and removes them if they are present).
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
These files are still there, and src/display/d.rgb/CVS/Tag contains:
Treleasebranch_11_april_2001_5_0_0
However, the most recent update adds the old version of d.rgb in
src/display/d.rgb/cmd, with src/display/d.rgb/cmd/CVS/Tag containing:Nreleasebranch_11_april_2001_5_0_0
Note: "T" indicates a branch tag, "N" indicates a non-branch tag.
AFAICT, any other files which had been removed from the release branch
have re-appeared in the latest version.
I've just done a "cvs update" (having first backed-up my working
directory) and examined the result. For all of the directories which
have recently reappeared, CVS/Tag contains
Nreleasebranch_11_april_2001_5_0_0, except those which have
subdirectories, for which CVS/Tag contains
Treleasebranch_11_april_2001_5_0_0.
AFAICT, this is consistent with someone adding a non-branch
releasebranch_11_april_2001_5_0_0 tag to all of the files at the head.
Now, clearly CVS shouldn't have allowed this to happen, but it did,
and I'm doubtful that it can actually be undone without restoring from
a backup (which is problematic because people have been continuing to
commit changes).
However, I'm currently executing
cvs tag -b releasebranch_14_august_2001_5_0_0
on what I think is a correct copy of the release branch, i.e. the one
I had before the problem occurred, with the subsequent commits (listed
in the ChangeLog) added.
If this works, people should be able to get a working copy of the
release branch with:
cvs update -r releasebranch_14_august_2001_5_0_0
--
Glynn Clements <glynn.clements@virgin.net>
Glynn,
it is good that you are making progress.
I am sorry that I've had not time to look into this yet.
(Seriously working overtime in this very moment.)
Bernhard
On Tue, Aug 14, 2001 at 01:10:07AM +0100, Glynn Clements wrote:
cvs tag -b releasebranch_14_august_2001_5_0_0
on what I think is a correct copy of the release branch, i.e. the one
I had before the problem occurred, with the subsequent commits (listed
in the ChangeLog) added.If this works, people should be able to get a working copy of the
release branch with:cvs update -r releasebranch_14_august_2001_5_0_0
--
Glynn Clements <glynn.clements@virgin.net>
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
On Tue, Aug 14, 2001 at 01:10:07AM +0100, Glynn Clements wrote:
Glynn Clements wrote:
AFAICT, this is consistent with someone adding a non-branch
releasebranch_11_april_2001_5_0_0 tag to all of the files at the head.
Now, clearly CVS shouldn't have allowed this to happen, but it did,
If it is a bug, maybe we have to look into a newer cvs server version
to upgrade to...
and I'm doubtful that it can actually be undone without restoring from
a backup (which is problematic because people have been continuing to
commit changes).
It might be possible if the change can be made easily on the ,v
file in the repository itself.
However, I'm currently executing
cvs tag -b releasebranch_14_august_2001_5_0_0
on what I think is a correct copy of the release branch, i.e. the one
I had before the problem occurred, with the subsequent commits (listed
in the ChangeLog) added.If this works, people should be able to get a working copy of the
release branch with:cvs update -r releasebranch_14_august_2001_5_0_0
Thanks for making progress.
I appologise for not having enough time to look into the issue right now.
Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
On Tue, Aug 14, 2001 at 01:10:07AM +0100, Glynn Clements wrote:
Glynn Clements wrote:
> These files are still there, and src/display/d.rgb/CVS/Tag contains:
>
> Treleasebranch_11_april_2001_5_0_0
>
> However, the most recent update adds the old version of d.rgb in
> src/display/d.rgb/cmd, with src/display/d.rgb/cmd/CVS/Tag containing:
>
> Nreleasebranch_11_april_2001_5_0_0
>
> Note: "T" indicates a branch tag, "N" indicates a non-branch tag.
>
> AFAICT, any other files which had been removed from the release branch
> have re-appeared in the latest version.I've just done a "cvs update" (having first backed-up my working
directory) and examined the result. For all of the directories which
have recently reappeared, CVS/Tag contains
Nreleasebranch_11_april_2001_5_0_0, except those which have
subdirectories, for which CVS/Tag contains
Treleasebranch_11_april_2001_5_0_0.AFAICT, this is consistent with someone adding a non-branch
releasebranch_11_april_2001_5_0_0 tag to all of the files at the head.
Now, clearly CVS shouldn't have allowed this to happen, but it did,
and I'm doubtful that it can actually be undone without restoring from
a backup (which is problematic because people have been continuing to
commit changes).However, I'm currently executing
cvs tag -b releasebranch_14_august_2001_5_0_0
on what I think is a correct copy of the release branch, i.e. the one
I had before the problem occurred, with the subsequent commits (listed
in the ChangeLog) added.If this works, people should be able to get a working copy of the
release branch with:cvs update -r releasebranch_14_august_2001_5_0_0
I just have ran a "find" on *yesterdays* CVS state (no update till now):
find . -name 'Entries' -exec grep Treleasebranch {} \; | wc -l
13323
find . -name 'Entries' -exec grep Treleasebranch {} \; |grep -v Trelease
-> nothing
find . -name 'Entries' -exec grep Nreleasebranch {} \;
-> nothing
Actually I don't find the Nreleasebranch. Checking the d.rgb I see:
more src/display/d.rgb/CVS/Entries
/Gmakefile/1.1.2.1/Sun Apr 29 23:01:06 2001//Treleasebranch_11_april_2001_5_0_0
/main.c/1.1.2.2/Fri Jun 8 15:42:54 2001//Treleasebranch_11_april_2001_5_0_0
D/cmd////
Does this make sense? Again, the last update yesterday (monday).
Markus