Re: how do I revert a bad commit without creating a new revision?
You missed a step.
Without that step the procedure will result in corruption (data loss) at
an undetermined time in the future.
Alan Barrett wrote on Fri, Jul 08, 2011 at 08:47:24 +0200:
> On Fri, 08 Jul 2011, Konstantin Kolinko wrote:
> >Another possibility: I think it is possible to effectively
> >truncate the repository by removing some files + running svnadmin
> >recover. Just theory - I have not tried it. I wish there were
> >official command (or instruction) how to truncate a repository (as
> >a cheap alternative to implementing obliteration).
>
> To truncate a repository that uses the "fsfs" format, so that you
> lose everything after a certain revision, you can try the following
> procedure. This is not supported, and might break everything.
>
> 1. Ensure that no new changes can be committed. (Tell your
> users to stop work, or rename the directory on the server to
> make it inaccessible, or activate some hook scripts that deny
> permission for any changes.)
>
> 2. Ensure that you have a backup.
>
> 3. Examine the "db/current" file in the repository. It should
> contain the most recent revision number. If it's not what
> you expected, then give up.
>
> 4. Change the "db/current" file, making it refer to the most
> recent "good" revision (e.g. 417810) instead of to the newer
> revisions that you want to disappear (e.g. 417811).
>
> 5. Delete the db/revs and db/revprops files corresponding to the
> revisions that you want to disappear (e.g. db/revs/417/417811
> and db/revprops/417/417811).
>
> 6. Allow access to the repository again.
>
> Any working copies that have references to the revisions that have
> disappeared, will now be broken. You may be able to fix them via
> "svn update -r${LAST_GOOD_REVISION}", but in the worst case, your
> users will have to delete the working copies and check them out
> again.
>
> --apb (Alan Barrett)
Re: how do I revert a bad commit without creating a new revision?
On Fri, 08 Jul 2011, Daniel Shahaf wrote:
You missed a step.
Without that step the procedure will result in corruption (data loss) at
an undetermined time in the future.
The last time I performed this sort of repository truncation
was with a fsfs repository format 5, db/format 3, without a
rep-cache.db (as created by svn version 1.5). I don't know what
else you have to do if you have db/format 4 with a rep-cache.db
(as created by svn version 1.6), but I imagine it's something like
using the sqlite3 command line client to "delete from rep_cache
where revision > ${last_good_revision};". Newer formats will
probably need different treatment. Again, this is all unsupported
and at your own risk.
--apb (Alan Barrett)
[original message repeated for reference:]
To truncate a repository that uses the "fsfs" format, so that you
lose everything after a certain revision, you can try the following
procedure. This is not supported, and might break everything.
1. Ensure that no new changes can be committed. (Tell your
users to stop work, or rename the directory on the server to
make it inaccessible, or activate some hook scripts that deny
permission for any changes.)
2. Ensure that you have a backup.
3. Examine the "db/current" file in the repository. It should
contain the most recent revision number. If it's not what
you expected, then give up.
4. Change the "db/current" file, making it refer to the most
recent "good" revision (e.g. 417810) instead of to the newer
revisions that you want to disappear (e.g. 417811).
5. Delete the db/revs and db/revprops files corresponding to the
revisions that you want to disappear (e.g. db/revs/417/417811
and db/revprops/417/417811).
6. Allow access to the repository again.
Any working copies that have references to the revisions that have
disappeared, will now be broken. You may be able to fix them via
"svn update -r${LAST_GOOD_REVISION}", but in the worst case, your
users will have to delete the working copies and check them out
again.
--apb (Alan Barrett)
Re: Trials with memcached
On Fri, Jul 08, 2011 at 01:56:07PM +1000, Tony Butt wrote: > On Fri, 2011-07-08 at 03:58 +0300, Daniel Shahaf wrote: > > Tony Butt wrote on Fri, Jul 08, 2011 at 10:41:43 +1000: > > > Probably don't want to do that. > > > We are in a commercial environment, with some 20 developers relying on > > > subversion - not the time for an alpha release. > > > > > > > I wasn't suggesting that you upgrade your production server! > I didn't really think you would be :-) > > > > Just that you install the alpha in a test environment to see if it > > improves the situation for you. (or if there is anything you see that > > requires modification /before/ the release --- before compatibility > > promises apply --- as in eg issue #3952) > > > My available test server also syncs the production repository to itself > as a hot spare. I am probably brave enough to install 1.7.0-alpha3 on > that, so long as there are no issues syncing from 1.6.17 to 1.7.0 Hi Tony, Doing pre-release testing is a great service to the community. For us, it is a lot easier to handle problems before the release, and we can respond to problem reports a lot quicker. After release we are bound by compatibility guarantees that sometimes make bug fixing a little more painful. And you might have to wait for weeks for enough fixes to accumulate before a new patch release is issued that addresses your particular problem. You will likely upgrade your setup to Subversion 1.7 eventually. Any problems that show up which are specific to your setup will have to be dealt with at that point. It's easier to spot and fix problems now, while you're not running 1.7 in production and while we're still moving towards the 1.7.0 release. One good way of testing is to make a somewhat recent (say, one week old) repository snapshot available though a 1.7 server reachable at a temporary URL. Then ask a few developers to put aside half an hour to try to use this temporary server (with fresh working copies) and perform whatever steps they performed on the real server again on this new server (checkout, update, commit, merge, ...). The developers can use either 1.6 or 1.7 clients to do this. Both should "just work". You don't need a separate server machine if you can install Subversion 1.6 and Subversion 1.7 in parallel (this may not be easy depending on what kind of package management you are using). You can start the 1.7 server on a different port (e.g. 8080), and point it at the repository snapshot which can be located anywhere in the machine's filesystem. This way your production setup is not affected at all, apart from sharing CPU and memory resources with the test setup. But if you cannot install 1.6 and 1.7 at the same time, you should use a separate machine for testing. Please do not install and use 1.7 on a Subversion server which you rely on, for whatever purpose (even for backup), just yet. You can get binaries of Subversion 1.7 alpha releases for some platforms here: http://subversion.apache.org/packages.html#pre-release Thanks! (And if you cannot test now, that's fine -- it just means you will get to test later, when it will be less convenient ;)
Re: Setting "use-commit-times" on project/directory/file basis
On Fri, Jul 8, 2011 at 01:56, Gingko wrote: > I read somewhere (actually here : http://www.aryehleib.com/Subversion.html ) > about an idea of adding a "svn:mtimes" property that could be set to files > or directories in order to have Subversion recording file modification times > (and restore them along with the corresponding files). Are there some plans > for implementing something like that? That post is over 3 years old, written by someone who is not affiliated with the Subversion project as far as I can tell. See http://subversion.tigris.org/issues/show_bug.cgi?id=1256 and the most recent discussion of a design spec that I can find, http://svn.haxx.se/dev/archive-2010-02/0127.shtml 1.7 is in the alpha release stage so this new feature, if it were to happen, wouldn't come until 1.8 (and this is noted on the issue tracker, as it's labeled 1.8-consider).
Re: UNS: Setting "use-commit-times" on project/directory/file basis
On Fri, 08 Jul 2011 07:56:53 +, Gingko wrote: ... > But I also have some files in my project, most of them being binary and not > subject to compilation (for example pictures or icons), that are part of an > auto-update process from the users point of view, and this auto-update > process uses the file's modification date in order to decide if the file > needs to be updated or not. This will drop on your feet as soon as you start working with multiple branches (at least if your only look for is-newer-than-the-previous-one). Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
RE: SVN not usable on a Mac (#2464)
> On Thu, Jul 07, 2011 at 11:14:13AM +0200, Vitus Piroutz wrote: > > > "I do understand your frustration, believe me. We have had a > number of complaints regarding this matter but the responsibility > for fixing this does lie squarely with CollabNet et al, and I know > that they have received more than their fair share of mails from > frustrated users in relation to this." > > > > > "No Subversion-offical fixes are available as of yet. As soon > as they are, we'll make them available." > > > > > "This problem is most likely related to Subversion's lack of > support for files containing accents and diacritics. " > > I am not going to comment on that statement from Cornerstone apart > from pointing out that it is showing deep ignorance of how the > Subversion community works. > > I am sorry you feel you wasted money on their product because > you were not aware of this problem before your purchase. > > > So please provide a huge badge on http://subversion.apache.org > > indicating to international users "Not for Mac users yet! (we > can't > > handle your filenames, but working hard since 2005 to fix this)" > > Yes, several people have spent many hours already trying to fix > this. > There have even been several face-to-face sessions between > Subversion > developers specifically trying to address this problem. I am not > aware > of many other issues that have received this much attention. > > Your venting is showing disrespect (or ignorance?) of the work that > has already gone into fixing this. And venting won't help anyone > advancing towards a solution. > > Rather, this issue requires somebody who is constructive and > willing > to drive discussion and design for a fix forward. > So please see the notes and discussions linked from the issue. > Please try to properly understand the problems involved here. > And please help us come up with a solution that solves all the > concerns raised by people who have already spent some of their > valuable time on this. > > All after cooling off on the couch with a hot beverage, of > course... > > Not that you're obliged to help. But if you don't have anything > to contribute apart from venting on the list please post your rants > on some blog or whatever but leave the lists alone with it. Thanks. <> A very even handed and well thought out reply.. and much more thoughtful than I would have given were I an svn dev. Stefan, you're a good man. Well done. BOb
Testing 1.7 pre-releases Re: Trials with memcached
Stefan Sperling wrote on Fri, Jul 08, 2011 at 11:13:05 +0200: > Doing pre-release testing is a great service to the community. > For us, it is a lot easier to handle problems before the release, > and we can respond to problem reports a lot quicker. > > After release we are bound by compatibility guarantees that > sometimes make bug fixing a little more painful. And you might > have to wait for weeks for enough fixes to accumulate before > a new patch release is issued that addresses your particular problem. > > You will likely upgrade your setup to Subversion 1.7 eventually. > Any problems that show up which are specific to your setup will > have to be dealt with at that point. It's easier to spot and fix > problems now, while you're not running 1.7 in production and while > we're still moving towards the 1.7.0 release.
Re: how do I revert a bad commit without creating a new revision?
Alan Barrett wrote on Fri, Jul 08, 2011 at 10:44:10 +0200:
> On Fri, 08 Jul 2011, Daniel Shahaf wrote:
> >You missed a step.
> >
> >Without that step the procedure will result in corruption (data loss) at
> >an undetermined time in the future.
>
> The last time I performed this sort of repository truncation was
> with a fsfs repository format 5, db/format 3, without a rep-cache.db
> (as created by svn version 1.5). I don't know what else you have to
> do if you have db/format 4 with a rep-cache.db (as created by svn
> version 1.6), but I imagine it's something like using the sqlite3
> command line client to "delete from rep_cache where revision >
> ${last_good_revision};".
Correct. Either run the SQL command you cite or rm rep-cache.db.
(And in either case one needs to verify that no txns currently in-flight
have already caught the rep-cache reference before it was removed from
the DB; I don't remember offhand at what point in the txn that happens.)
> Newer formats will probably need different
> treatment. Again, this is all unsupported and at your own risk.
>
True. And thanks again for including these unequivocal "Unsupported
/ At your own risk" warnings very clearly. :-)
> --apb (Alan Barrett)
>
Best,
Daniel
> [original message repeated for reference:]
>
> >>To truncate a repository that uses the "fsfs" format, so that you
> >>lose everything after a certain revision, you can try the following
> >>procedure. This is not supported, and might break everything.
> >>
> >> 1. Ensure that no new changes can be committed. (Tell your
> >> users to stop work, or rename the directory on the server to
> >> make it inaccessible, or activate some hook scripts that deny
> >> permission for any changes.)
> >>
> >> 2. Ensure that you have a backup.
> >>
> >> 3. Examine the "db/current" file in the repository. It should
> >> contain the most recent revision number. If it's not what
> >> you expected, then give up.
> >>
> >> 4. Change the "db/current" file, making it refer to the most
> >> recent "good" revision (e.g. 417810) instead of to the newer
> >> revisions that you want to disappear (e.g. 417811).
> >>
> >> 5. Delete the db/revs and db/revprops files corresponding to the
> >> revisions that you want to disappear (e.g. db/revs/417/417811
> >> and db/revprops/417/417811).
> >>
> >> 6. Allow access to the repository again.
> >>
> >>Any working copies that have references to the revisions that have
> >>disappeared, will now be broken. You may be able to fix them via
> >>"svn update -r${LAST_GOOD_REVISION}", but in the worst case, your
> >>users will have to delete the working copies and check them out
> >>again.
> >>
> >>--apb (Alan Barrett)
Is it possible to svnsync across platform OS and SVN versions?
Do two SVN servers need to be running identical release versions in order to use svnsync on them? What about the OS? I built an SVN server on Ubuntu server 10.04 LTS, --version says 1.6.6 (r40053) Now my guys want me to mirror it read-only onto a Windows 7 box and since most of the binaries I find to download are for 1.6.17, I figured I'd check with you guys first if this will (should) work. Is there an SVN 1.6.6 binary for Windows 7 64-bit anywhere that you know of? Thanks - Geoff
Re: Is it possible to svnsync across platform OS and SVN versions?
On Jul 8, 2011, at 17:26, Geoff Hoffman wrote: > Do two SVN servers need to be running identical release versions in order to > use svnsync on them? Probably a good idea but I don't think it's 100% essential. > What about the OS? Shouldn't be necessary. > I built an SVN server on Ubuntu server 10.04 LTS, --version says 1.6.6 > (r40053) > > Now my guys want me to mirror it read-only onto a Windows 7 box and since > most of the binaries I find to download are for 1.6.17, I figured I'd check > with you guys first if this will (should) work. > > Is there an SVN 1.6.6 binary for Windows 7 64-bit anywhere that you know of? I would not recommend intentionally downgrading the version on Windows. Instead, if possible, upgrade the version on Ubuntu to 1.6.17.
Re: SVN not usable on a Mac (#2464)
On Jul 7, 2011, at 04:14, Vitus Piroutz wrote: > issue # 2464 "Canonicalize / stringprep UTF-8 filenames to handle composed / > decomposed differences shown by e.g. Mac OS X HFS+". There are unofficial / incomplete patches that attempt to provide at least a partial solution to this. For example, you could install Subversion with MacPorts [1] using the +unicode_path variant: sudo port install subversion +unicode_path I have used Subversion on my Mac successfully for over 6 years but do not use filenames with non-ASCII characters so I do not know how well this patch works. I also don't know if Versions can use the Subversion that is installed by MacPorts or whether it has its own internal copies of the Subversion libraries. [1] http://www.macports.org/
