Problem with the repository: bogus date
I've noticed the following error: $ svn log -r2 https://svn.macosforge.org/repository/macports svn: Bogus date -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Vincent Lefevre wrote:
I've noticed the following error:
$ svn log -r2 https://svn.macosforge.org/repository/macports svn: Bogus date
It is really a "Bogus date", as you can see in the following log: --snip-- | $ svn log --xml -r2 https://svn.macosforge.org/repository/macports | <?xml version="1.0"?> | <log> | <logentry | revision="2"> | <author>landonf</author> | <date>http://svn.seven:8080/code</date> | <msg>Initial revision | </msg> | </logentry> | </log> --snap-- Maybe this happened on import from an older repository or you can put the blame on cvs2svn. At least you can read the log message with --xml. Rainer
On Sep 3, 2007, at 18:51, Rainer Müller wrote:
Vincent Lefevre wrote:
I've noticed the following error:
$ svn log -r2 https://svn.macosforge.org/repository/macports svn: Bogus date
It is really a "Bogus date", as you can see in the following log:
--snip-- | $ svn log --xml -r2 https://svn.macosforge.org/repository/macports | <?xml version="1.0"?> | <log> | <logentry | revision="2"> | <author>landonf</author> | <date>http://svn.seven:8080/code</date> | <msg>Initial revision | </msg> | </logentry> | </log> --snap--
Very sorry! That was my fault. I've now fixed the svn:date property of revision 2 so the log should work again. The timestamp of revision 1 and revision 3 are identical, so I set revision 2 to that same timestamp. (I issued a bad "svn propset" command the other day. I was meaning to change my own repo but I was missing an argument or something and then I couldn't figure out what I'd done. I must've been in my dports tree when I issued the command.)
On Sep 4, 2007, at 01:18, Ryan Schmidt wrote:
On Sep 3, 2007, at 18:51, Rainer Müller wrote:
Vincent Lefevre wrote:
I've noticed the following error:
$ svn log -r2 https://svn.macosforge.org/repository/macports svn: Bogus date
It is really a "Bogus date", as you can see in the following log:
--snip-- | $ svn log --xml -r2 https://svn.macosforge.org/repository/macports | <?xml version="1.0"?> | <log> | <logentry | revision="2"> | <author>landonf</author> | <date>http://svn.seven:8080/code</date> | <msg>Initial revision | </msg> | </logentry> | </log> --snap--
Very sorry! That was my fault. I've now fixed the svn:date property of revision 2 so the log should work again. The timestamp of revision 1 and revision 3 are identical, so I set revision 2 to that same timestamp.
(I issued a bad "svn propset" command the other day. I was meaning to change my own repo but I was missing an argument or something and then I couldn't figure out what I'd done. I must've been in my dports tree when I issued the command.)
Oh, and I wanted to say: if we had the post-revprop-change email hook, I would've noticed and been able to fix the problem right away. :-) http://trac.macports.org/projects/macports/ticket/12593
On Sep 4, 2007, at 12:03 PM, Ryan Schmidt wrote:
Very sorry! That was my fault. I've now fixed the svn:date property of revision 2 so the log should work again. The timestamp of revision 1 and revision 3 are identical, so I set revision 2 to that same timestamp.
(I issued a bad "svn propset" command the other day. I was meaning to change my own repo but I was missing an argument or something and then I couldn't figure out what I'd done. I must've been in my dports tree when I issued the command.)
Oh, and I wanted to say: if we had the post-revprop-change email hook, I would've noticed and been able to fix the problem right away. :-)
Maybe the repository shouldn't allow unrevisioned property changes at all? It seems like a good way to stomp on version history.
Landon Fuller wrote:
On Sep 4, 2007, at 12:03 PM, Ryan Schmidt wrote:
Very sorry! That was my fault. I've now fixed the svn:date property of revision 2 so the log should work again. The timestamp of revision 1 and revision 3 are identical, so I set revision 2 to that same timestamp.
(I issued a bad "svn propset" command the other day. I was meaning to change my own repo but I was missing an argument or something and then I couldn't figure out what I'd done. I must've been in my dports tree when I issued the command.)
Oh, and I wanted to say: if we had the post-revprop-change email hook, I would've noticed and been able to fix the problem right away. :-)
Maybe the repository shouldn't allow unrevisioned property changes at all? It seems like a good way to stomp on version history.
It's nice to fix typos in log messages. But it could be limited to svn:log for that purpose with a pre-revprop-change like this: --snip-- #!/bin/bash REPOS="$1" REV="$2" USER="$3" PROPNAME="$4" if [ "$PROPNAME" = "svn:log" ]; then exit 0; fi exit 1 --snap-- This allows changes to svn:log only while rejecting changes to other unversioned revision properties. Rainer
On Sep 7, 2007, at 09:43, Rainer Müller wrote:
Landon Fuller wrote:
On Sep 4, 2007, at 12:03 PM, Ryan Schmidt wrote:
Very sorry! That was my fault. I've now fixed the svn:date property of revision 2 so the log should work again. The timestamp of revision 1 and revision 3 are identical, so I set revision 2 to that same timestamp.
(I issued a bad "svn propset" command the other day. I was meaning to change my own repo but I was missing an argument or something and then I couldn't figure out what I'd done. I must've been in my dports tree when I issued the command.)
Oh, and I wanted to say: if we had the post-revprop-change email hook, I would've noticed and been able to fix the problem right away. :-)
Maybe the repository shouldn't allow unrevisioned property changes at all? It seems like a good way to stomp on version history.
It's nice to fix typos in log messages. But it could be limited to svn:log for that purpose with a pre-revprop-change like this:
The log being unversioned, that still seems a dangerous tool to leave open. Here at work, unrevisioned properties require local access to the repository -- nobody else has this. I only recall one instance in the past three years that I've been asked to change a commit log message on behalf of any of our developers, and I've never done so for myself. I'd personally rather have a few uncorrected typos in commit logs than the potential for history-changing. Auditing the changes is an improvement, but why even open the door? -landonf
Landon Fuller wrote:
On Sep 7, 2007, at 09:43, Rainer Müller wrote:
Landon Fuller wrote:
On Sep 4, 2007, at 12:03 PM, Ryan Schmidt wrote:
Very sorry! That was my fault. I've now fixed the svn:date property of revision 2 so the log should work again. The timestamp of revision 1 and revision 3 are identical, so I set revision 2 to that same timestamp.
(I issued a bad "svn propset" command the other day. I was meaning to change my own repo but I was missing an argument or something and then I couldn't figure out what I'd done. I must've been in my dports tree when I issued the command.)
Oh, and I wanted to say: if we had the post-revprop-change email hook, I would've noticed and been able to fix the problem right away. :-)
Maybe the repository shouldn't allow unrevisioned property changes at all? It seems like a good way to stomp on version history.
It's nice to fix typos in log messages. But it could be limited to svn:log for that purpose with a pre-revprop-change like this:
The log being unversioned, that still seems a dangerous tool to leave open. Here at work, unrevisioned properties require local access to the repository -- nobody else has this. I only recall one instance in the past three years that I've been asked to change a commit log message on behalf of any of our developers, and I've never done so for myself.
I'd personally rather have a few uncorrected typos in commit logs than the potential for history-changing. Auditing the changes is an improvement, but why even open the door?
We do this all the time in the Subversion's own repository. The standard way of handling it is to use mailer.py to send a diff of the before and after log message to some list. This can be set up in the post-revprop-change script. It's common to edit log messages. In fact, the recommended procedure for a reverse merge of a revision is to now go back and edit the log message on the reverted revision indicating that it was reverted and in which revision. Regards, Blair -- Blair Zajac, Ph.D. http://www.orcaware.com/svn/
On Sep 7, 2007, at 14:29, Blair Zajac wrote:
Landon Fuller wrote:
On Sep 7, 2007, at 09:43, Rainer Müller wrote:
It's nice to fix typos in log messages. But it could be limited to svn:log for that purpose with a pre-revprop-change like this: The log being unversioned, that still seems a dangerous tool to leave open. Here at work, unrevisioned properties require local access to the repository -- nobody else has this. I only recall one instance in the past three years that I've been asked to change a commit log message on behalf of any of our developers, and I've never done so for myself. I'd personally rather have a few uncorrected typos in commit logs than the potential for history-changing. Auditing the changes is an improvement, but why even open the door?
We do this all the time in the Subversion's own repository. The standard way of handling it is to use mailer.py to send a diff of the before and after log message to some list. This can be set up in the post-revprop-change script.
It's common to edit log messages. In fact, the recommended procedure for a reverse merge of a revision is to now go back and edit the log message on the reverted revision indicating that it was reverted and in which revision.
That's crazy talk! That sort of information is generally conveyed in bug tracking systems, not by changing history in your source repository. It may be common in the subversion project's usage, but I don't see why it's an inherent necessity (or even a very good idea). Given that this discussion started with accidental destruction of a non-revisioned historical property, it's obviously not an academic concern. Two options: - Treat the commit message as immutable as the commit itself. or - Allow people to fix typos and change history, with the potential for destructive changes. The first option seems both simplier and safer, is the default configuration, and is the standard expectation of a source control system -- no data can be irretrievably lost. -landonf
Landon Fuller wrote:
On Sep 7, 2007, at 14:29, Blair Zajac wrote:
Landon Fuller wrote:
On Sep 7, 2007, at 09:43, Rainer Müller wrote:
It's nice to fix typos in log messages. But it could be limited to svn:log for that purpose with a pre-revprop-change like this: The log being unversioned, that still seems a dangerous tool to leave open. Here at work, unrevisioned properties require local access to the repository -- nobody else has this. I only recall one instance in the past three years that I've been asked to change a commit log message on behalf of any of our developers, and I've never done so for myself. I'd personally rather have a few uncorrected typos in commit logs than the potential for history-changing. Auditing the changes is an improvement, but why even open the door?
We do this all the time in the Subversion's own repository. The standard way of handling it is to use mailer.py to send a diff of the before and after log message to some list. This can be set up in the post-revprop-change script.
It's common to edit log messages. In fact, the recommended procedure for a reverse merge of a revision is to now go back and edit the log message on the reverted revision indicating that it was reverted and in which revision.
That's crazy talk! That sort of information is generally conveyed in bug tracking systems, not by changing history in your source repository. It may be common in the subversion project's usage, but I don't see why it's an inherent necessity (or even a very good idea).
That's a crazy response :) If you need to revert a bad commit for some reason, say the committer introduced a bug, why should it appear in a ticket? It's not the natural place for it. For people that are looking at work that is done, it is nice to see in the commit log for the reverted revision that is was reverted. Also, I don't think most open-source projects use ticket tracking systems to document the code they worked on, so that's another reason to allow log message changes. We don't open a ticket in MacPorts or in svn just to document some new work that is going to happen, nor that I reverted something.
Given that this discussion started with accidental destruction of a non-revisioned historical property, it's obviously not an academic concern. Two options: - Treat the commit message as immutable as the commit itself. or - Allow people to fix typos and change history, with the potential for destructive changes.
The first option seems both simplier and safer, is the default configuration, and is the standard expectation of a source control system -- no data can be irretrievably lost.
That is the default for Subversion repositories. I recommend that we allow log message changes, but only if the old and new log message are emailed somewhere. Blair
participants (5)
-
Blair Zajac
-
Landon Fuller
-
Rainer Müller
-
Ryan Schmidt
-
Vincent Lefevre