Re: Displaying commit logs via Apache / mod_dav_svn

[Mat Booth]

On 14 August 2012 01:30, Daevid Vincent  wrote:
> 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.
>
>

There is an Apache fork of Trac called Bloodhound in the incubator if
you are interested in trying it out:
https://issues.apache.org/bloodhound/wiki

>
>
>> -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
>> >>
>> >>
>> >>
>



-- 
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com

Libraries and projects into SVN

[Leonardo Laface de Almeida]

Hello.

 

We desire to insert some projects into SVN and we have now to deal with some
witch uses the same library. The developers here said that we always
actualize the last library in order to be compatible with the older ones. 

 

We have talked about it and we think we have to create an individual
repository for the library and the developers should actualize it very often
manually. I mean, every time someone wants to change some project, he must
to check out the project version and the libraries versions required for it.
After developing or correction, the developer must actualize the project and
the libraries separated.

 

My questions are:

 

1)  Is that right? I mean, Is there any better other way to control
versions of  libraries used for several projects?

 

2)  Is it possible in SVN to make it automatic ? In other words, when
the developer actualize (commit, merge, etc...) some project, is it possible
to actualize the libraries together? One of us said it's possible to do this
in GIT using sub-repositories. Is it possible in SVN? If so, is there any
tutorial or advices to do this?

 

I'm already glad for answers.  

 

 

Regards,

Leonardo 

 

Re: Libraries and projects into SVN

[peter . fodrek]

On Tuesday, August 14, 2012 09:14:47 Leonardo Laface de Almeida wrote:


  
We have talked about it and we think we have to create an individual 
repository for the library and the developers should actualize it very often 
manually. I mean, every time someone wants to change some project, he must to 
check out the project version and the libraries versions required for it. 
After developing or correction, the developer must actualize the project and 
the libraries separated. 
  
My questions are: 
  
1)  Is that right? I mean, Is there any better other way to control 
versions of  libraries used for several projects? 

I think use of svn:extrenals is the best soluition for this. Svn: extrenals 
connects repostiory or its part as an directory inside project.  When someone 
changes file inside this directory and commit, canges in taht directory are 
commited into that shared repository or directory



Peter

svn diff --summarize url encoding

[James French]

Hi,

I just noticed that svn 1.6 did not url encode the output of svn diff 
-summarize (ie spaces in files not replaced with %20), whereas svn 1.7 does. 
There is nothing in changes.txt about it. Is the 1.7 behaviour correct?

Cheers,
James

Re: Libraries and projects into SVN

[Ulrich Eckhardt]

Am 14.08.2012 14:14, schrieb Leonardo Laface de Almeida:

We desire to insert some projects into SVN and we have now to deal with some
witch uses the same library. The developers here said that we always
actualize the last library in order to be compatible with the older ones.


Okay, so there is a component (a library) that is shared between 
different projects, right? Or is it that you check in the compiled .DLLs 
or .LIBs separately to the source code?


This question is very important because of the different implications 
and strategies for approaching it. Reading the rest of your mail also 
doesn't make it clear, so it is impossible to give you proper advise 
without you answering that part first.


Note that what Peter suggested mostly deals with how to share the 
content between different projects using it and not so much with how to 
store it. In any case, svn:externals are a good tool but they are not 
always the right one.



Greetings!

Uli

**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

RES: Libraries and projects into SVN

[Leonardo Laface de Almeida]

Hi,

The system here is a bit complex and I will try to explain it.

We have two main projects (P1 and P2). They are compiled in separated
environments, generating *.exe different files, but they use the same source
code allocated into a module (M1), that contains some functionalities like
file system, file transfer, etc.

We have also one library (L1) with 80% of source code equivalent of P1, and
it is compiled separated from P1, generating a L1.dll file.

The library L1 is used by three other application projects (A1, A2 and A3). 

So, three main situations:
 
1) When source code from P1 changes module M1, the P2 must have access to
it, and vice-versa. 
2) When source code from P1 changes shared code from L1, the L1 source code
must be actualized, and vice-versa.   
3) When L1.dll changes, A1, A2 and A3 should automatically start to use the
new L1 created.


I'm still a bit lost here how to share the codes into SVN. I think I may
create one repository to each one (P1, P2, M1, L1, A1, A2 and A3). The
problem is doing all svn commands for each one. 

For example, If I will change L1, I must to check out P1 and M1 to compile
it. Then, after changes, I must commit P1, M1 and L1, for source code and
commit the L1.dll file for A1, A2 and A3. It's unlikelly doing this
manually. 

In other hand, I also think it's unlikelly to create only one repository for
all these projects.  
 
Finally, our system is a bit more complex than it, but the main structure is
this.

Thanks again for your suggestions.

Regards
Leonardo


-Mensagem original-
De: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] 
Enviada em: terça-feira, 14 de agosto de 2012 09:43
Para: users@subversion.apache.org
Assunto: Re: Libraries and projects into SVN

Am 14.08.2012 14:14, schrieb Leonardo Laface de Almeida:
> We desire to insert some projects into SVN and we have now to deal with
some
> witch uses the same library. The developers here said that we always
> actualize the last library in order to be compatible with the older ones.

Okay, so there is a component (a library) that is shared between 
different projects, right? Or is it that you check in the compiled .DLLs 
or .LIBs separately to the source code?

This question is very important because of the different implications 
and strategies for approaching it. Reading the rest of your mail also 
doesn't make it clear, so it is impossible to give you proper advise 
without you answering that part first.

Note that what Peter suggested mostly deals with how to share the 
content between different projects using it and not so much with how to 
store it. In any case, svn:externals are a good tool but they are not 
always the right one.


Greetings!

Uli


**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Visit our website at http://www.dominolaser.com

**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten
bestimmt und kann vertrauliche Informationen enthalten. Bitte
benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte
Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf
weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt
werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht
verantwortlich.

**

Interesting mergeinfo corruption bug

[Chris J Smith]

Hi,

I've encountered a rather interesting merging bug. We are using the following 
stack:

Client side: TSVN 1.7.7 on Windows 7 x64
Server side: Apache 2.0.27, Subversion 1.7.5 on Windows 2008 Server R2 behind 
an IIS 7.5 ARR proxy.

The issue is as follows (with false names of course :-):

1. We have trunk and two branches running (ba, bb). Merges have been done from 
each branch.

2. bob merges a revision 12 from ba into trunk. This causes the mergeinfo 
property to be set on trunk to:

/svn/project/ba:10,11,12 #(adding the 12).
/svn/project/bb:8,9,13

3. bill comes along and immediately merges revision 14 from bb into trunk. This 
causes the merge info to set on the root to:

/svn/project/ba:10,11 #(removing the 12?!?!?)
/svn/project/bb:8,9,13,14 #(adding the 14)

This unexpectedly removes rev 12 from the mergeinfo for a branch which is not 
being merged against. Inevitably this means that rev 12 now shows up as 
eligible again.

We've been playing whack a mole with this for a couple of weeks now. The 
problem is entirely intermittent and there appears to be no way of reliably 
isolating it (I've tried for days now).

There is the possibility of human error here either on my understanding or at 
this end but it's shown up on several people's workstations now.

Does anyone know why this occurs or can anyone help us?

Best Regards,

Chris Smith


[cid:imageb49554.png@03f105ab.20a84782]
Best Tech/ Software Provider- PA Awards 3 years running, voted for by Financial 
Advisers.
[cid:imageb8bb42.png@42860fd3.72ca41b9]

The information contained in this message is confidential and may also be 
privileged. It is intended only for the addressee named above. The unauthorised 
use, disclosure, copying or alteration of this message is strictly prohibited. 
If you are not the addressee (or responsible for delivery of the message to the 
addressee), please notify the originator immediately by return message and 
destroy the original message. This message and any attachments have been 
scanned for viruses prior to leaving the originators network. The originator 
does not guarantee the security of this message and will not be responsible for 
any damages arising from any alteration of this message by a third party or as 
a result of any virus being passed on. Registered in England No. 05206315. 
Registered Office IntelliFlo Limited, Quarrydown, 21E Rydens Road, Walton on 
Thames, KT12 3AB.


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__<><>

Re: Libraries and projects into SVN

[Les Mikesell]

On Tue, Aug 14, 2012 at 9:05 AM, Leonardo Laface de Almeida
 wrote:
>
> So, three main situations:
>
> 1) When source code from P1 changes module M1, the P2 must have access to
> it, and vice-versa.
> 2) When source code from P1 changes shared code from L1, the L1 source code
> must be actualized, and vice-versa.
> 3) When L1.dll changes, A1, A2 and A3 should automatically start to use the
> new L1 created.
>
>
> I'm still a bit lost here how to share the codes into SVN. I think I may
> create one repository to each one (P1, P2, M1, L1, A1, A2 and A3). The
> problem is doing all svn commands for each one.
>
> For example, If I will change L1, I must to check out P1 and M1 to compile
> it. Then, after changes, I must commit P1, M1 and L1, for source code and
> commit the L1.dll file for A1, A2 and A3. It's unlikelly doing this
> manually.
>
> In other hand, I also think it's unlikelly to create only one repository for
> all these projects.

It doesn't really matter whether each project has its own repository
or not, as long as the shared components each have their own top-level
subdirectory.  For each shared thing needed for a build, just use an
svn external reference in the project that needs it to pull it into a
subdirectory of the workspace.  If you want to use pre-built .dlls,
you can commit them back as well.   For ongoing development you might
let the externals reference the trunk versions of the components, but
you will probably want to establish a naming convention for your
branches and tags from the start.   As you approach release versions
of each projects you would normally want to tie the externals to
tagged versions of each component in case the component development
continues in incompatible/untested ways on the trunk.

-- 
   Les Mikesell
  lesmikes...@gmail.com

Issues compiling SVN 1.7.5 on Solaris Sparc 9

[Ferreira, Matthew]

Downloaded the source (the binaries that I could find were compiled for 10, so 
I need to compile). Downloaded the latest sqllite client and it stumbled on 
that. Per the README it worked on 3.6.18, so found that and got past that, now 
the make is throwing symbol errors. I've searched the archives (and google) 
with no luck as to the possible cause. Any help would be appreciated. I am 
running the make as root.



/bin/bash /tmp/svn_src/subversion-1.7.5/libtool --tag=CC --silent 
--mode=compile gcc -DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT 
-D_LARGEFILE64_SOURCE  -g -O2   -pthreads  -I./subversion/include 
-I./subversion  -I/usr/local/apache2/include   -I/usr/local/apache2/include 
 -I/tmp/svn_src/subversion-1.7.5/sqlite-amalgamation  -o subversion/svn/util.lo 
-c subversion/svn/util.c
cd subversion/svn && /bin/bash /tmp/svn_src/subversion-1.7.5/libtool --tag=CC 
--silent --mode=link gcc  -g -O2   -pthreads   -rpath /usr/local/lib  -o svn  
add-cmd.lo blame-cmd.lo cat-cmd.lo changelist-cmd.lo checkout-cmd.lo 
cleanup-cmd.lo commit-cmd.lo conflict-callbacks.lo copy-cmd.lo delete-cmd.lo 
diff-cmd.lo export-cmd.lo help-cmd.lo import-cmd.lo info-cmd.lo list-cmd.lo 
lock-cmd.lo log-cmd.lo main.lo merge-cmd.lo mergeinfo-cmd.lo mkdir-cmd.lo 
move-cmd.lo notify.lo patch-cmd.lo propdel-cmd.lo propedit-cmd.lo 
propget-cmd.lo proplist-cmd.lo props.lo propset-cmd.lo relocate-cmd.lo 
resolve-cmd.lo resolved-cmd.lo revert-cmd.lo status-cmd.lo status.lo 
switch-cmd.lo tree-conflicts.lo unlock-cmd.lo update-cmd.lo upgrade-cmd.lo 
util.lo ../../subversion/libsvn_client/libsvn_client-1.la 
../../subversion/libsvn_wc/libsvn_wc-1.la 
../../subversion/libsvn_ra/libsvn_ra-1.la 
../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_diff/libsvn_diff-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la -L/usr/local/apache2/lib 
-laprutil-1 -L/usr/local/apache2/lib -lapr-1  -lsocket
ld: warning: file ../../subversion/libsvn_wc/.libs/libsvn_wc-1.so: linked to 
/tmp/svn_src/subversion-1.7.5/subversion/libsvn_wc/.libs/libsvn_wc-1.so: 
attempted multiple inclusion of file
ld: warning: file ../../subversion/libsvn_ra/.libs/libsvn_ra-1.so: linked to 
/tmp/svn_src/subversion-1.7.5/subversion/libsvn_ra/.libs/libsvn_ra-1.so: 
attempted multiple inclusion of file
ld: warning: file ../../subversion/libsvn_delta/.libs/libsvn_delta-1.so: linked 
to 
/tmp/svn_src/subversion-1.7.5/subversion/libsvn_delta/.libs/libsvn_delta-1.so: 
attempted multiple inclusion of file
ld: warning: file ../../subversion/libsvn_diff/.libs/libsvn_diff-1.so: linked 
to /tmp/svn_src/subversion-1.7.5/subversion/libsvn_diff/.libs/libsvn_diff-1.so: 
attempted multiple inclusion of file
ld: warning: file ../../subversion/libsvn_subr/.libs/libsvn_subr-1.so: linked 
to /tmp/svn_src/subversion-1.7.5/subversion/libsvn_subr/.libs/libsvn_subr-1.so: 
attempted multiple inclusion of file
Undefined   first referenced
symbol in file
libintl_bind_textdomain_codeset 
/tmp/svn_src/subversion-1.7.5/subversion/libsvn_subr/.libs/libsvn_subr-1.so
libintl_dngettext   .libs/info-cmd.o
libintl_bindtextdomain  
/tmp/svn_src/subversion-1.7.5/subversion/libsvn_subr/.libs/libsvn_subr-1.so
libintl_dgettext.libs/add-cmd.o
ld: fatal: Symbol referencing errors. No output written to .libs/svn
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `subversion/svn/svn'I am not 
subscribed and would appreciate a direct cc

Matt Ferreira
Web Services Engineer, Sr. - Managed Web Serivces
NaviSite - A Time Warner Cable Company
mferre...@navisite.com
Office:  (978) 946-7747
Mobile: (978) 631-9810
[cid:image001.jpg@01CD7A28.67F4CF30]



This e-mail is the property of NaviSite, Inc. It is intended only for the 
person or entity to which it is addressed and may contain information that is 
privileged, confidential, or otherwise protected from disclosure. Distribution 
or copying of this e-mail, or the information contained herein, to anyone other 
than the intended recipient is prohibited.
<>

Re: Issues compiling SVN 1.7.5 on Solaris Sparc 9

[Daniel Shahaf]

Add --disable-nls to your configure flags.

Ferreira, Matthew wrote on Tue, Aug 14, 2012 at 14:24:18 -0400:
> ld: warning: file ../../subversion/libsvn_subr/.libs/libsvn_subr-1.so: linked 
> to 
> /tmp/svn_src/subversion-1.7.5/subversion/libsvn_subr/.libs/libsvn_subr-1.so: 
> attempted multiple inclusion of file
> Undefined   first referenced
> symbol in file
> libintl_bind_textdomain_codeset 
> /tmp/svn_src/subversion-1.7.5/subversion/libsvn_subr/.libs/libsvn_subr-1.so
> libintl_dngettext   .libs/info-cmd.o
> libintl_bindtextdomain  
> /tmp/svn_src/subversion-1.7.5/subversion/libsvn_subr/.libs/libsvn_subr-1.so
> libintl_dgettext.libs/add-cmd.o
> ld: fatal: Symbol referencing errors. No output written to .libs/svn
> collect2: ld returned 1 exit status
> *** Error code 1
> make: Fatal error: Command failed for target `subversion/svn/svn'I am not 
> subscribed and would appreciate a direct cc

Re: Interesting mergeinfo corruption bug

[Daniel Shahaf]

Chris J Smith wrote on Tue, Aug 14, 2012 at 16:04:22 +0100:
> Hi,
> 
> I've encountered a rather interesting merging bug. We are using the following 
> stack:
> 
> Client side: TSVN 1.7.7 on Windows 7 x64
> Server side: Apache 2.0.27, Subversion 1.7.5 on Windows 2008 Server R2 behind 
> an IIS 7.5 ARR proxy.
> 
> The issue is as follows (with false names of course :-):
> 
> 1. We have trunk and two branches running (ba, bb). Merges have been done 
> from each branch.
> 
> 2. bob merges a revision 12 from ba into trunk. This causes the mergeinfo 
> property to be set on trunk to:
> 
> /svn/project/ba:10,11,12 #(adding the 12).

Not 10-12 ? 

> /svn/project/bb:8,9,13
> 
> 3. bill comes along and immediately merges revision 14 from bb into trunk. 
> This causes the merge info to set on the root to:
> 
> /svn/project/ba:10,11 #(removing the 12?!?!?)
> /svn/project/bb:8,9,13,14 #(adding the 14)
> 
> This unexpectedly removes rev 12 from the mergeinfo for a branch which is not 
> being merged against. Inevitably this means that rev 12 now shows up as 
> eligible again.
> 

Can you provide 'svn log -q -v -r 0:12' output of a repository that
shows the problem?  I can't look into it myself but I think it would be
helpful.

> We've been playing whack a mole with this for a couple of weeks now. The 
> problem is entirely intermittent and there appears to be no way of reliably 
> isolating it (I've tried for days now).
> 
> There is the possibility of human error here either on my understanding or at 
> this end but it's shown up on several people's workstations now.
> 
> Does anyone know why this occurs or can anyone help us?
> 
> Best Regards,
> 
> Chris Smith
> 
> 
> [cid:imageb49554.png@03f105ab.20a84782]
> Best Tech/ Software Provider- PA Awards 3 years running, voted for by 
> Financial Advisers.
> [cid:imageb8bb42.png@42860fd3.72ca41b9]
> 
> The information contained in this message is confidential and may also be 
> privileged. It is intended only for the addressee named above. The 
> unauthorised use, disclosure, copying or alteration of this message is 
> strictly prohibited. If you are not the addressee (or responsible for 
> delivery of the message to the addressee), please notify the originator 
> immediately by return message and destroy the original message. This message 
> and any attachments have been scanned for viruses prior to leaving the 
> originators network. The originator does not guarantee the security of this 
> message and will not be responsible for any damages arising from any 
> alteration of this message by a third party or as a result of any virus being 
> passed on. Registered in England No. 05206315. Registered Office IntelliFlo 
> Limited, Quarrydown, 21E Rydens Road, Walton on Thames, KT12 3AB.
> 
> 
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __

Re: Repairing or removing broken revisions

[Daniel Shahaf]

PR wrote on Mon, Aug 13, 2012 at 22:12:51 -0700:
> On Mon, Aug 13, 2012 at 7:10 PM, Trent Fisher  wrote:
> > 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...

You didn't break threading, but you preceded yoru text by three
">"-quoting levels instead of the normal zero.

Re: Repairing or removing broken revisions

[Daniel Shahaf]

Trent Fisher wrote on Mon, Aug 13, 2012 at 22:10:57 -0400:
> 
> 
> 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.
> >>
...
> >>
> >>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).
> >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

Did this actually work?  If the r5 rev file is 0 bytes long, it
should fail immediately.  (The same is true for the r5 revprops
file, but for a different reason.)

> 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: Documentation for the XSLT file specificed by the SVNIndexXSLT directive

[Daniel Shahaf]

Robert Heller wrote on Sat, Aug 11, 2012 at 12:44:29 -0400:
> Does there exist documentation for this file?  Is there information on
> what templates are supported and what @ vars are defined?  I want to
> customize the file referenced by the SVNIndexXSLT, but without
> documentation I am pretty much groping blindly.
> 

There is an example tools/xslt/svnindex.xsl in the source tree; further
documentation should be (but, AFAICT, isn't) in the book (CC'd by way of
bug report / feature request).

> 
> -- 
> 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
> 
> 
>   

Current Wisdom on NFS/CIFS Checkouts & Working Copies

[Mark Bober]

What's the current wisdom on doing checkouts to NFS and CIFS?

I'm seeing general checkout times of a given repository in the 2 second range 
for local disk, and that jumps all the way up to a minute and a half or more 
going over CIFS or NFS (Windows 2008R2 fileserver, running OpenText NFS for the 
NFS side), in either 1.6 or 1.7.

An 'svn export' of the same repository to the same mounts hovers around 20 
seconds, revealing that 'checkout' is doing a lot more work that's not going 
well over the remote mount.

This subject doesn't seem to come up very much, and I may have missed the key 
post that would answer this for me. I'm aware from my research that Subversion 
may had been attempting certain locking operations, and also tended towards a 
lot of file renaming/duplication that made it less than efficient over NFS/CIFS.

Thanks for your time!

Mark