Subject: Rescuing a repository - msg#00017

Previous Message by Date:

Re: [PATCH] German translation, take 2

Hi Luebbe, >Michael S=FCss and me proudly present the german translation for subversion. >I hope that this time the mime-type of the patch is correct. We are eagerly >awaiting comments. Absent any comments I think the community agrees to your translation... Do you have an e-mail address for Michael too; then, when I commit this, I can give proper credit. >The patch includes two files, de.po which is of course, the dictionary, plus >a teminology file, that we like to include in the subversion repository as >well. We think the terminology is important, because there are always >several possibilities to translate things and we'd like to keep the wording >consistent and encourage future translators to use the same terminology. I see the list you created is not very long. The Polish translation has a list like this built into the po file. Would that be a suitable solution for yours as well? >It's not so easy to do this, because the original is sometimes inconsistent >or misleading. Maybe a terminology file for english wouldn't be such a bad >idea too ;-) If you have a list of any inconsistencies I'd like to know about them. >We marked some (three) translations as fuzzy, because nothing we could think >of made sense... Thanks for the work! bye, Erik.

Next Message by Date:

Re: Rescuing a repository

On Friday 14 May 2004 13:37, Jan Evert van Grootheest wrote: > Marc, > > You could at least dump the rest of the repository using -r! > You'd only lose one revision. > > -- Jan Evert Thanks for the idea, you mean like: svnadmin dump -r 0:335 /export/rescue >dump.0:335 svnadmin dump -r 337:HEAD /export/rescue >dump.337:HEAD leaving out 336... but how can I reimport these dumps into a working repository again ? Revision 336 contains three disk images of one of our products specifically for three different customers (commit e-mails rule ;-)... so at least leaving this revision wouldn't create "holes" in the sources, but still: this would be the "everything else failed" method (that is, if it works at all, I don't know whether these dumps can be imported back into the repository). C'ya, Marc -- Marc Haisenko Systemspezialist Webport IT-Services GmbH mailto: haisenko@xxxxxxxxxx

Previous Message by Thread:

[PATCH] Re: SVN Log gotcha...

* Ben Collins-Sussman <sussman@xxxxxxxxxx> [2004-05-11 14:41]: > (Anyone wanna write a patch to project_faq.html for this question?) Sure... here's a patch. Quite a bit of the wording is taken directly from the book, but put together in a way that (hopefully) makes a nice, bite-sized FAQ answer. Log: Add a FAQ entry for "How can I change a log message?" * www/project_faq.html (change-log-msg): New question and answer. Index: www/project_faq.html =================================================================== --- www/project_faq.html (revision 9687) +++ www/project_faq.html (working copy) @@ -55,6 +55,8 @@ <li><a href="#reposperms">How do I set repository permissions correctly?</a></li> <li><a href="#readonly">Why do read-only operations still need repository write access?</a></li> <li><a href="#removal">How do I completely remove a file from the repository's history?</a></li> +<li><a href="#change-log-msg">How do I change the log message for a revision + after it's been committed?</a></li> <li><a href="#patch">How do I submit a patch for Subversion?</a></li> <li><a href="#in-place-import">How can I do an in-place 'import' (i.e. add a tree to subversion without moving or deleting the @@ -857,7 +859,57 @@ href="http://svnbook.red-bean.com/html-chunk/ch05.html">chapter 5</a> of the Subversion book for details about this.</p> +<![CDATA[=========================================================]]> +<h3><a name="change-log-msg"> +How do I change the log message for a revision after it's been committed? +</a></h3> + +<p>Log messages are kept in the repository as properties attached to each +revision. By default, the log message property (<em>svn:log</em>) cannot be +edited once it is committed. That is because changes to <a +href="http://svnbook.red-bean.com/svnbook/ch05.html#svn-ch-5-sect-1.2">revision +properties</a> (of which <em>svn:log</em> is one) cause the property's +previous value to be permanently discarded, and Subversion tries to prevent +you from doing this accidentally. However, there are a couple of ways to get +Subversion to change a revision property.</p> + +<p>The first way is for the repository administrator to enable revision +property modifications. This is done by creating a hook called +"pre-revprop-change" (see <a +href="http://svnbook.red-bean.com/svnbook/ch05s02.html#svn-ch-5-sect-2.1">this +section</a> in the Subversion book for more details about how to do this). +The "pre-revprop-change" hook has access to the old log message before it is +changed, so it can preserve it in some way (for example, by sending an email). +Once revision property modifications are enabled, you can change a revision's +log message by passing the --revprop switch to <b>svn propedit</b> or <b>svn +propset</b>, like either one of these:</p> + +<pre> +$ svn propedit -r N --revprop svn:log URL +$ svn propset -r N --revprop svn:log "new log message" URL +</pre> + +<p>where N is the revision number whose log message you wish to change, and +URL is the location of the repository. If you run this command from within a +working copy, you can leave off the URL.</p> + +<p>The second way of changing a log message is to use <b>svnadmin setlog</b>. +This must be done by referring to the repository's location on the filesystem. +You cannot modify a remote repository using this command.</p> + +<pre> +$ svnadmin setlog REPOS_PATH -r N FILE +</pre> + +<p>where REPOS_PATH is the repository location, N is the revision number whose +log message you wish to change, and FILE is a file containing the new log +message. If the "pre-revprop-change" hook is not in place (or you want to +bypass the hook script for some reason), you can also use the --bypass-hooks +option. However, if you decide to use this option, be very careful. You may +be bypassing such things as email notifications of the change, or backup +systems that keep track of revision properties.</p> + <![CDATA[=========================================================]]> <h3><a name="patch">How do I submit a patch for Subversion?</a></h3> -- Mike -- Michael W. Thelen I never did give anybody hell. I just told the truth and they thought it was hell. -- Harry S Truman signature.pgp Description: Digital signature

Next Message by Thread:

Re: Rescuing a repository

On Friday 14 May 2004 13:37, Jan Evert van Grootheest wrote: > Marc, > > You could at least dump the rest of the repository using -r! > You'd only lose one revision. > > -- Jan Evert Thanks for the idea, you mean like: svnadmin dump -r 0:335 /export/rescue >dump.0:335 svnadmin dump -r 337:HEAD /export/rescue >dump.337:HEAD leaving out 336... but how can I reimport these dumps into a working repository again ? Revision 336 contains three disk images of one of our products specifically for three different customers (commit e-mails rule ;-)... so at least leaving this revision wouldn't create "holes" in the sources, but still: this would be the "everything else failed" method (that is, if it works at all, I don't know whether these dumps can be imported back into the repository). C'ya, Marc -- Marc Haisenko Systemspezialist Webport IT-Services GmbH mailto: haisenko@xxxxxxxxxx