Re: Displaying commit logs via Apache / mod_dav_svn
There is also WebSVN: http://www.websvn.info/ If you want to go a bare-bones approach, you could use ReposStyle: http://reposstyle.com/ On 08/13/2012 02:19 AM, Nico Kadel-Garcia wrote: Viewvc works very well... Sent from my iPhone On Aug 11, 2012, at 12:44, Robert Heller wrote: Is it possible to display subversion commit logs directly via mod_dav_svn in a web browser? Do I need to install some additional (third-party) software to do this? -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
RE: Displaying commit logs via Apache / mod_dav_svn
I've used (and love) http://trac.edgewall.org/ Awesome integration with SVN plus a Wiki and Bugtracker to boot (all tied together so you can reference commits or pages from each other. It has a lovely AJAXy source tree browser, with diff tools, and all sorts of joy. It's FREE too. d. There are only 11 types of people in this world. Those that think binary jokes are funny, those that don't, and those that don't know binary. > -Original Message- > From: Trent Fisher [mailto:trent.fis...@oracle.com] > Sent: Monday, August 13, 2012 4:31 PM > To: users@subversion.apache.org > Subject: Re: Displaying commit logs via Apache / mod_dav_svn > > There is also WebSVN: http://www.websvn.info/ > > If you want to go a bare-bones approach, you could use ReposStyle: > http://reposstyle.com/ > > On 08/13/2012 02:19 AM, Nico Kadel-Garcia wrote: > > Viewvc works very well... > > > > Sent from my iPhone > > > > On Aug 11, 2012, at 12:44, Robert Heller wrote: > > > >> Is it possible to display subversion commit logs directly via > >> mod_dav_svn in a web browser? Do I need to install some additional > >> (third-party) software to do this? > >> > >> > >> -- > >> Robert Heller -- 978-544-6933 / hel...@deepsoft.com > >> Deepwoods Software-- http://www.deepsoft.com/ > >> () ascii ribbon campaign -- against html e-mail > >> /\ www.asciiribbon.org -- against proprietary attachments > >> > >> > >>
Re: Repairing or removing broken revisions
On 08/01/2012 10:49 AM, Johan Corveleyn wrote: On Wed, Aug 1, 2012 at 2:24 PM, Joachim Sauer wrote: Hello, I'm currently reworking backups of multiple SVN repositories. In the process I found out that one of those repositories has three broken revisions. The problem is that the revision files in the revs directory for those 3 revisions are of size 0 (those contain the actual data of the revision, as far as I understand). This means that I can't use svn dump (as it stops at that broken revision) and I can't use svnsync. For the backup itself I can still use svn hotcopy (the previous way of doing a backup), so this will be my workaround. I was able to find out the affected paths in the repository and luckily the latest revision of those paths can be checked out without a problem (so we "only" lost history, not current data). But a broken repository is not desirable and I should attempt to fix it as much as possible. Losing the information of those three revisions (and a few related ones, probably) would not be a major problem, but the repository as a whole should be in a consistent state (to allow svnadmin dump to work, for example). Is there a way to remove the broken revisions and still keep the rest of the repository intact? Ideally without requiring everyone to make new clean checkouts because the repository became incompatible. regards Joachim Sauer P.S.: unfortunately there are no working backups of the broken revisions, as the corruption seems to be pretty old (older than our last full backup). Since you know the affected paths, I think one possible way is to do an svnsync, while excluding the "corrupted paths" by way of path-based authz (i.e. make the affected paths unreadable by the svnsync user, using an authz file on the source repository). After that, re-import the "corrupted files" from one of your working copies. I think everyone will have to re-checkout though, because you'll have a new repository with slightly altered history. So it wouldn't be safe to give this new repository the same repos-uuid, and act like it's the same. If you search the mailinglist archives, you might find some more posts about this svnsync recovery trick (excluding broken files). I had a similar situation, though I only had one damaged revision. I did a dump in three segments, up to the bad rev, the bad rev and the remaining revs, something like this (assuming rev 5 is the bad one): svnadmin dump -r0:4 /some/repos > p1 svnadmin dump --incremental -r5 /some/repos > p2 svnadmin dump --incremental -r6:HEAD /some/repos > p3 Then I manually doctored p2 to indicate that the rev is broken (but leave the original comment intact), then load all three into a fresh repository (cat p1 p2 p3 | svnadmin load /some/new/repos) The advantage of this is that the uuid and rev numbers remain the same, so existing workspaces will work. And this would preserve all other history of the given file. I just did this on a production repository two weeks ago, and no complaints so far. trent...
Re: Repairing or removing broken revisions
On Mon, Aug 13, 2012 at 7:10 PM, Trent Fisher wrote: > > > On 08/01/2012 10:49 AM, Johan Corveleyn wrote: >> >> On Wed, Aug 1, 2012 at 2:24 PM, Joachim Sauer wrote: >>> >>> Hello, >>> >>> I'm currently reworking backups of multiple SVN repositories. In the >>> process I found out that one of those repositories has three broken >>> revisions. The problem is that the revision files in the revs >>> directory for those 3 revisions are of size 0 (those contain the >>> actual data of the revision, as far as I understand). This means that >>> I can't use svn dump (as it stops at that broken revision) and I can't >>> use svnsync. >>> >>> For the backup itself I can still use svn hotcopy (the previous way of >>> doing a backup), so this will be my workaround. >>> >>> I was able to find out the affected paths in the repository and >>> luckily the latest revision of those paths can be checked out without >>> a problem (so we "only" lost history, not current data). >>> >>> But a broken repository is not desirable and I should attempt to fix >>> it as much as possible. Losing the information of those three >>> revisions (and a few related ones, probably) would not be a major >>> problem, but the repository as a whole should be in a consistent state >>> (to allow svnadmin dump to work, for example). >>> >>> Is there a way to remove the broken revisions and still keep the rest >>> of the repository intact? Ideally without requiring everyone to make >>> new clean checkouts because the repository became incompatible. >>> >>> regards >>> Joachim Sauer >>> >>> P.S.: unfortunately there are no working backups of the broken >>> revisions, as the corruption seems to be pretty old (older than our >>> last full backup). >> >> Since you know the affected paths, I think one possible way is to do >> an svnsync, while excluding the "corrupted paths" by way of path-based >> authz (i.e. make the affected paths unreadable by the svnsync user, >> using an authz file on the source repository). After that, re-import >> the "corrupted files" from one of your working copies. >> >> I think everyone will have to re-checkout though, because you'll have >> a new repository with slightly altered history. So it wouldn't be safe >> to give this new repository the same repos-uuid, and act like it's the >> same. >> >> If you search the mailinglist archives, you might find some more posts >> about this svnsync recovery trick (excluding broken files). >> > I had a similar situation, though I only had one damaged revision. I did a > dump in three segments, up to the bad rev, the bad rev and the remaining > revs, something like this (assuming rev 5 is the bad one): > > svnadmin dump -r0:4 /some/repos > p1 > svnadmin dump --incremental -r5 /some/repos > p2 > svnadmin dump --incremental -r6:HEAD /some/repos > p3 > Then I manually doctored p2 to indicate that the rev is broken (but leave > the original comment intact), then load all three into a fresh repository > (cat p1 p2 p3 | svnadmin load /some/new/repos) > > The advantage of this is that the uuid and rev numbers remain the same, so > existing workspaces will work. And this would preserve all other history of > the given file. > > I just did this on a production repository two weeks ago, and no complaints > so far. > > trent... > >>> I would do slightly differently .. >>> let us say that 5 10 and 15 are 3 revs of the file to keep it simple >>> as suggested before I would do the three part dump >>> but I will load to 9 then look at the diff beween 9 and 15 subtract the >>> diff for 15 >>> and checkin as rev 10 to the repository with the expected log and not >>> failing to mention >>> that this was engineered checkin [ it will be difficult if the files # are >>> more for a checkin ..in my case was max >>> 2 some times 1 file .. since we migrated from CVS >>>... then continue on to load 11 to 15 .. >>> just my 2c ... sorry if I accidentally broke the posting sequence...
