Re: Repo browser not opening

[Eric Johnson]

In order to get useful help from this list, you will probably need to
provide more details than you're offering here.

What repository browser are you using? What version? What operating system
are you on? What kind of Subversion server are you connecting to? What
version? What operating system on the server?

Keep in mind, this is the open-source Subversion users list - so if the
problem is with a commercial server, or with the client software, it may be
appropriate for a different mailing list.

Eric

On Wed, Apr 8, 2020 at 10:29 PM Ayush Sharma 
wrote:

> When i try to access my repo browser, it hangs and displays the message
> please wai while repository browser is initializing. Please help.
>
> --
> Thanks with regards,
> Ayush Sharma,
> ASE/SLAM,
> CRIS, ITPI, New Delhi.
>

Re: Cannot get info for a file that was inside of file-replaced directory

[Eric Johnson]

Interesting.

It appears that svn ls of "dir@1" works fine. As does svn cat of "dir/file@1".
svn proplist of "dir/file@1" appears to work as well.

svn log -v appears to be incomplete, as it shows "dir" removed, but not
also added in the revision.

svn info fails, as you note.

Looks like a bug to me.

Eric.


On Mon, Nov 18, 2019 at 1:53 AM Иван Селин  wrote:

> Hi!
>
> I think I've found a bug in subversion client. Setup is as follows:
> 1. Create directory with a file in it — commit 1
> 2. Replace directory with other file — commit 2
> 3. Call "svn info dir/file@1" — it should give information about dir/file
> at revision 1, but it fails saying that "dir" is a file at latest revision:
>
> svn: E160016: Failure opening '/dir' in revision 2
> svn: E160016: '/dir' is not a directory in filesystem
> '0bc899d5-c233-4fed-98a3-8705ddfc96c4'
> But directory can be listed, it shows the file, and file can be listed too:
>   $ svn info file:///tmp/subversion-info-on-replaced-file/repo/dir@1
> Path: dir
> URL: file:///tmp/subversion-info-on-replaced-file/repo/dir
> Relative URL: ^/dir
> Repository Root: file:///tmp/subversion-info-on-replaced-file/repo
> Repository UUID: 0bc899d5-c233-4fed-98a3-8705ddfc96c4
> Revision: 1
> Node Kind: directory
> Last Changed Author: ivanselin
> Last Changed Rev: 1
> Last Changed Date: 2019-11-18 11:38:16 +0300 (Пн, 18 ноя 2019)
>
>   $ svn list file:///tmp/subversion-info-on-replaced-file/repo/dir@1
> file
>   $ svn list file:///tmp/subversion-info-on-replaced-file/repo/dir/file@1
> file
>
> So, only "info" does not work. It seems that it's performing directory
> check against HEAD instead of provided peg revision. Adding --revision key
> changes nothing. This is trunk svn (1.14.0-dev, r1869957), svn 1.9.7 does
> not have this bug, it correctly shows info.
>
> Sample reproduction script attached.
>
> Regards,
> Ivan.
>

Re: Subversion and JIRA integration

[Eric Johnson]

Hi Ragu,

Your question is sort of a tricky one. Well, at least parts of it are. But
here's an attempt at an answer.

On Sun, Sep 29, 2019 at 9:50 PM Ragu Nathan  wrote:

>
> Hi,
>
> I would like to know the Subversion can be integrate with JIRA bug
> tracking tool.
>

Yes, but it depends on your requirements, and how many development
resources you're willing to throw at it, if a commercial vendor doesn't
provide it already.


> Ex: I found an  issue in software coding and create a problem report to
> address root cause, analysis, documents updates , etc and I will use the
> JIRA to track all above, but Subversion is a configuration management tool
> to store data ( source code, documents, etc).
>

Subversion is a version control tool, not a configuration management tool.
While it may certainly be possible to use Subversion in the manner implied,
the definition of "configuration management" may lead to requirements that
Subversion is less than ideal for.


> Questions:
> 1. If I use the JIRA tool to address an issue , address all sort of
> analysis, proposed solutions, implementation details and I want to update
> the documents or source code in Subversion, is there any way to get into
> Subversion from JIRA? Not hyperlink. Real integrate environment. In this
> case I can check if any updates were made in to the documents or source
> code , which problem reporting # was used to fix the issue.
>

As I understand it, JIRA includes an extension API. It certainly should be
possible to extend JIRA to get more detailed information about links into
Subversion, without, as you indicate "hyperlinking".

There exist integrations into JIRA already for tighter coupling with
Subversion, so you could start with those, to see if any of those meet your
requirements.


> 2. Are both tools integrate together?
>

It is left to one's imagination. Both have APIs, so it is possible to add
tighter integration to both. For details of how to integrate from
Subversion's perspective, check out the "hook" documentation:

http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.hooks

Atlassian definitely offers APIs from the JIRA side:
https://developer.atlassian.com/server/framework/atlassian-sdk/


> 3. If so, how much would it cost for floating licence?
>

This mailing list isn't going to be a good source of information about
that. And that assumes that you can find an existing commercial vendor of
extension(s) that meet your needs.

Eric.



>
>
> Thanks
> Ragu.P
>
>

Python 3.X bindings for Subversion on MacOS?

[Eric Johnson]

I'm writing some python hook scripts to work with Subversion.

I've used MacPorts to install Subversion. Looking around I see that
MacPorts only has a package for "subversion-python27bindings", and none for
python37. Is this just a limitation of MacPorts packaging of the official
python bindings? From the mailing list, it looks like this might have been
a limitation as little as six months ago

.

I could not find a python packaging of the official python bindings on pypi.

Should I use subvertpy instead, or maybe pysvn? What's the right approach
here?

Eric.

Re: which review tools are suitable for codes versioned by svn

[Eric Johnson]

ReviewBoard.

Eric

> On Aug 10, 2019, at 9:18 PM, wuzhouhui  wrote:
> 
> Hi,
> 
> I'm searching some review tools which are suitable for codes versioned
> by Subversion, any recommends?
> 

Re: Reg: SVN subversion checkout issue in ubuntu

[Eric Johnson]

Hi Surendar,

More help might arise on this list if you can provide more details.

What version of the Subversion client are you using (svn --version)?
What version of Subversion is running on the server you're trying to
access, and what host OS?

On Tue, Jul 16, 2019 at 12:42 AM Surendar Dharani <
surenda...@apaengineering.com> wrote:

> Hi,
>
> Thanks a lot for your svn service. IT is very useful thing. But I have a
> problem in svn with ubuntu 18.04.
>
> After installed subversion i tried to checkout or list from svn+ssh url
> but my bad luck its not working it throws following error.
>
> Error : Unable to connect to a repository at URL
> 'svn+ssh://DOMAIN/SVN_PATH'
>

I'm assuming that DOMAIN/SVN_PATH is an edit you made to hide the details
of your organization?


> To better debug SSH connection problems, remove the -q option from 'ssh'
> in the [tunnels] section of your Subversion configuration file.
>

Did you try this step of removing the -q option? What shows up on the
command line?

Eric.


> Network connection closed unexpectedly
>
> I tried lot of ways from the forums to get out from this issue. But sadly
> i can't, please help me.
> *With Regards,*
> *Surendar D.*
> *Web Developer,*
> *APA Engineering,*
> MEPZ-SEZ Tambaram,
> Chennai.
>
>
>
>
>
>
>

Re: Unsubscribe

[Eric Johnson]

If you look in the original source of the email, you'll see one of the
message headers is:

List-Unsubscribe: 

I suspect you'll have more success with that address.

Eric.



On Sun, Jun 16, 2019 at 10:25 AM Michael Mueller  wrote:

> Unsubscribe
>

Re: Importing from a working copy ... bad idea?

[Eric Johnson]

Sounds like you might want to take advantage of svn:externals.

http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html

Eric.

On Wed, Apr 17, 2019 at 3:51 PM Mun Johl 
wrote:

> Hi,
>
> We're using SVN version 1.8.19 on Red Hat Enterprise Linux 6.8 .
>
> For a new project we are about to undertake, I need to create a new
> directory in our repository (let's call it ^/trunk/new_project).
> However, most of the directories/files in the "new_project" directory
> will come from other areas of the same repository that are being
> consolidated into a new directory.
>
> I was thinking of creating this new directory structure and then doing
> an 'svn import'.  However, that will result in the loss of the existing
> logs, right?
>
> If I want to maintain the logs of the leveraged files, is my only
> recourse to use 'svn copy' to get all of the leveraged files into
> "new_project"?  Unfortunately, that will add a lot of complexity for the
> 100's of files that will need to reside under ^/trunk/new_project.
>
> Any suggestions would be welcomed.
>
> Regards,
>
> --
> Mun
>

Re: Add changes from a local svn repo to the same but older repo on a server with history

[Eric Johnson]

On Tue, Apr 2, 2019 at 10:08 PM  wrote:

>
> On 04/01 09:23, Eric Johnson wrote:
> > Hi mcc,
> >
> > On Mon, Apr 1, 2019 at 5:40 AM  wrote:
> >
> > > Hi,
> > >
> > > (I am not subscribed and appreciate to be CC:ed by any reply to my
> > > question. Thank you! :) )
> > >
> > > The setup is some freaking weired and I am no native speaker...
> > >
> > > The setup: There is a remote SVN-server, I can only access via PC "A"
> at
> > > place "A".
> > > I am working, compiling, developing at PC "B" at place "B".
> > > Changeing places and PCs is  hmmm ... "less effective"
> > > hrrrmmm.
> > >
> > > I am working with repo "A" on the SVN-Server.
> > >
> >
> > Quite the unpleasant setup
> >
> >
> > >
> > > To be able to check in changed sources not only at the beginning of the
> > > project and at
> > > the end of the project but in logically reasonable portions I came
> > > accross an idea...
> > > from which I dont know whether it works or not
> > >
> > > 1) Export the repo "A" from the server.
> > >
> >
> > svnrdump
> >
> >
> > > 2) Create an empty local repo of the same structure.
> > >
> >
> > svnadmin create
> >
> >
> > > 3) Import the sources into the local repo at PC "B"
> > >
> >
> > svnadmin load
> >
> >
> > > 4) Check in logically sized portioned into the local repo.
> > >
> >
> > svn add, svn commit , ...
> >
> > 5) If completed transfer the local repo to PC "B".
> > >
> >
> > 6) Transfer the changes with historie, logs, etc into the server on top
> > > of the repo.
> > >
> >
> > svnadmin dump --incremental ...
> >
> > svnadmin load ...
> > # but this is where the whole thing goes off the rails.
> >
> > The load command would only work if nobody else touches the repository
> (in
> > a way that conflicts) in the meantime. Assuming this is unlikely.
> >
> > The most obvious alternative that I can think of is to use "git-svn".
> > Instead of pushing changes to Subversion, push them to Git. Keep changes
> in
> > Git in sync with the main Subversion repository.
> >
> > Whenever you're ready, push changes from Git back to Subversion.
> >
> > Eric.
> >
> >
> > >
> > > Point 5) and 6) gives me headaches
> > >
> > > How can I minimize the PC "A" <=> PC "B" changes by simutanously being
> > > able to checkin
> > > logically sized portions including all other informations?
> > >
> > > Thanks a lot for any help in advance!
> > > Cheers!
> > > mcc
> > >
>
>
> Hi Eric,
>
> thank you very much for your informations and help! Very
> appreciated!!! Upto but not including 5) it was already know to me...
> 5) is were the magic (at least for me) begins... :)
>
> Would it be an option to lock the whole repo (with announcement
> before) for the time of doing a 'svnadmin load"...or do you
> meant with "nobody touches the repository in the meantime" the time
> between 1) and end of 6)...?
>

Unfortunately, it means that nobody touches the repository between 1 and
6

I think the git-svn approach is likely to be the most successful strategy.

Eric.



>
> Cheers!
> mcc
>
>
>
>
>
>

Re: Add changes from a local svn repo to the same but older repo on a server with history

[Eric Johnson]

Hi mcc,

On Mon, Apr 1, 2019 at 5:40 AM  wrote:

> Hi,
>
> (I am not subscribed and appreciate to be CC:ed by any reply to my
> question. Thank you! :) )
>
> The setup is some freaking weired and I am no native speaker...
>
> The setup: There is a remote SVN-server, I can only access via PC "A" at
> place "A".
> I am working, compiling, developing at PC "B" at place "B".
> Changeing places and PCs is  hmmm ... "less effective"
> hrrrmmm.
>
> I am working with repo "A" on the SVN-Server.
>

Quite the unpleasant setup


>
> To be able to check in changed sources not only at the beginning of the
> project and at
> the end of the project but in logically reasonable portions I came
> accross an idea...
> from which I dont know whether it works or not
>
> 1) Export the repo "A" from the server.
>

svnrdump


> 2) Create an empty local repo of the same structure.
>

svnadmin create


> 3) Import the sources into the local repo at PC "B"
>

svnadmin load


> 4) Check in logically sized portioned into the local repo.
>

svn add, svn commit , ...

5) If completed transfer the local repo to PC "B".
>

6) Transfer the changes with historie, logs, etc into the server on top
> of the repo.
>

svnadmin dump --incremental ...

svnadmin load ...
# but this is where the whole thing goes off the rails.

The load command would only work if nobody else touches the repository (in
a way that conflicts) in the meantime. Assuming this is unlikely.

The most obvious alternative that I can think of is to use "git-svn".
Instead of pushing changes to Subversion, push them to Git. Keep changes in
Git in sync with the main Subversion repository.

Whenever you're ready, push changes from Git back to Subversion.

Eric.


>
> Point 5) and 6) gives me headaches
>
> How can I minimize the PC "A" <=> PC "B" changes by simutanously being
> able to checkin
> logically sized portions including all other informations?
>
> Thanks a lot for any help in advance!
> Cheers!
> mcc
>

Re: --normalize-probs doesn't do its thing

[Eric Johnson]

Just FYI, I've found that svnsync automatically fixes these problems. My
pattern for old repositories has been to perform the svnadmin dump / load
with --bypass-prop-validation.

Then use svnsync to copy yet again to another copy of the repository. Then
remove the sync properties on rev 0.

Eric.


On Tue, Mar 26, 2019 at 8:35 AM Evgeny Kotkov 
wrote:

> Thorsten Goetzke  writes:
>
> >
> uls/trunk/uls/TestAutomation/UMS_Testmanagement/02_Implementation/java/TestManagementUI
> > ...svnadmin: E125005: A property with invalid line ending found in
> > dumpstream; consider using --normalize-props while loading.
> >
> > Are there some catches on how to use --normalize-probs?
>
> Apparently, there is a bug in the implementation of --normalize-props
> that only makes it automatically fix line endings in the values of the
> revision properties, but not node properties (as per the code around
> load-fs-vtable.c: set_node_property()).
>
> I'll put fixing that on my TODO list.
>
>
> Regards,
> Evgeny Kotkov
>

Re: Why does svn up give me a different file than in the repo

[Eric Johnson]

Possibly a line-ending conversion?

http://svnbook.red-bean.com/nightly/en/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style

Check to see if the svn:eol-style property is set.

Eric

On Tue, Mar 5, 2019 at 10:34 AM Satya Mishra  wrote:

> Hi,
>
> I recently encountered a strange problem while trying to revert a failed
> experiment. svn revert apparently succeeded, but kept giving me the
> unreverted files. Example shell output showing the problem is below. The
> sha1sum of the file doesn't match the sha1sum from repo in this working
> copy. But it does in a freshly checked out working copy. I am using
> Subversion 1.10.3 on CentOS 7. I'll greatly appreciate any insight into why
> this might happen.
>
> > rm -f projfile
> > svn up projfile
> Updating 'projfile':
> Restored 'projfile'
> At revision 6878.
> > sha1sum projfile
> c58a4e654e2e8ac565e9705a7f83901a3ea7e321  projfile
> > svn info projfile
> Path: projfile
> Name: projfile
> Working Copy Root Path: ~/proj
> URL: svn://repohost/proj/trunk/projfile
> Relative URL: ^/proj/trunk/projfile
> Repository Root: svn://repohost
> Repository UUID: .
> Revision: 6878
> Node Kind: file
> Schedule: normal
> Last Changed Author: satya
> Last Changed Rev: 5734
> Last Changed Date: 2018-03-27 12:03:21 -0700 (Tue, 27 Mar 2018)
> Text Last Updated: 2019-03-05 10:03:46 -0800 (Tue, 05 Mar 2019)
> Checksum: 6c0ff2498b56833e603908a66a284351ad0ec7dc
>
>
>
>

Re: Subversion Version Control

[Eric Johnson]

Hi Gennar,

On Fri, Jan 25, 2019 at 12:07 PM Gillead, Gennar <
gennar.gill...@teradata.com> wrote:

> Eric,
>
> Thanks for response. I haven't used SVN but my client currently uses it
> and looking for a certain functionality before considering replacing it.
> To be more specific can you define your own keyword replacement variables?
> Based on documentation I have found it doesn't allow that functionality.
>

Just this seems to be relevant to your question.

http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.keywords.html

Eric.


>
> Thanks,
>
> Gennar
>
> Sent via the Samsung Galaxy S9+, an AT 4G LTE smartphone
>

Re: Subversion Version Control

[Eric Johnson]

On Thu, Jan 24, 2019 at 10:56 PM Gillead, Gennar <
gennar.gill...@teradata.com> wrote:

> Subversion,
>
>
>
> Does tool have functionality to change key words in code as its migration
> through SDLC from DEV to QA to UA/SIT to PROD? Below is  replacement that
> will have to occur during migration.
>
>1. “_DEV” to “QA Naming Standard”  for QA migration? In this instance
>all references of “_DEV” will have to be replaced.
>   - Example: USER_DATA_DEV to USER_DATA
>2. “QA Naming Standard” to “_UAT/SIT”  for UAT and/or SIT migration?
>   - USER_DATA to  USER_DATA_UAT and/or USER_DATA_SIT  based on flag
>   or other indicator selected with in application?
>3. Removal of “_UAT/SIT”  for  PROD migration?
>   - USER_DATA_UAT or USER_DATA_SIT to  USER_DATA DATA based on flag
>   or other indicator selected with in application?
>
> It is difficult to tell from your question whether or not Subversion fits
the bill. Based on your question, it doesn't sound like you've actually
used Subversion. Since it is free to download and install, and can even be
used without a server for limited use-cases, perhaps experiment with it,
and ask a more specific concrete question?

None of the significant version control systems available (Git, Mercurial,
SVN) do much in the way of *changing* code. Mostly, they *store* code.
Logic about changing code is outside the purview of what the systems do
(with a small exception for tracking specific property values as part of
the contents of files, a mostly discouraged practice).

Eric.

>

Re: help of SVN

[Eric Johnson]

On Fri, Jan 11, 2019 at 3:34 AM public1979  wrote:

> Hello，
> I'm a new user of subversion.
> My version is "svn, version 1.6.11 (r934486)",i have some questions about
> *svnsync* .
> I made a svn mirror from server A to server B. it could work  first few
> days until an accidental power failure.
> Now it can't work ,what can i do .
>

Sounds like your situation must be quite frustrating.


> Please help me,
>

Several places to start.

Please note that you're using an old, unsupported version of Subversion.
For the most useful help, you'll need to upgrade to a supported version.
There's lots of help online to assist in that process, and people who have
previously asked on this mailing list, so checking the archives for this
mailing list will help if you get stuck.

Also, the (brief) details make it sound like perhaps something went wrong
with the machines during the power failure. It is unclear what operating
system you are using from your brief description, but I'd start with
running standard operating system diagnostics, to verify that the hardware
is not damaged, that the disk volumes have not been corrupted, and that the
necessary parts of the operating system are where they are supposed to be.
And finally, perhaps the Subversion repositories themselves were damaged /
corrupted. Try "svnadmin verify" on your repositor(y/ies).

And finally, to get the best help from this list, your questions will
likely need to be more specific / detailed. For example, when you say "now
it can't work", what does that mean? What error messages do you see? How do
you know it doesn't work? What *does* work (can you perform svnadmin
commands, or svnlook commands, for example?), as that will help eliminate
possible failures.

Good luck!

Eric


> Thank U.
>
>
>
>
>

Re: Using wild cards to specify usernames in svn auth file

[Eric Johnson]

I don't believe that Subversion implements a way to do that directly. For
the server I help manage, we generate access files from a combination of
sources, which then lets us auto-generate lists of users, rather than
maintain a list in an editor. Sounds like that could be the right approach
in this case.

Eric.

On Fri, Oct 26, 2018 at 7:06 AM William Muriithi 
wrote:

> Hello
>
> I have an SVN where a user can login through two accounts.  For
> example, will...@example.com and will...@example.org.   The access
> rules however are tailored for one domain
>
> I want to prevent users in one domain being able to commit.  I however
> don't want to list them all again.  Its there a way one can use a wild
> card to match all users in a specific domain in the auth file?
> Something like *@example.org to match all users who login from
> example.org accounts?
>
> Any pointer is highly appreciated.
>
> Regards,
> William
>

Re: Migration a Git archive to subversion

[Eric Johnson]

In general, this isn't precisely possible, because Git has a different
data-model than Subversion, which is probably why you don't see many tools
automating this.

Tags: In Git, a tag is just a pointer to a revision. In Subversion, a tag
is a separate revision of the repository, represented by a separate path.

Branches: Git tracks merging of branches with a special merge-commit
object, whereas Subversion uses the merge-info property. The discrepancy
can lead to subtle differences over time.

So I'm not sure you can find a fully automated tool to migrate either
direction.

However, having said all that, try the "git-svn" connector. Here's someone
with a similar sounding task:
http://www.draconianoverlord.com/2010/03/05/existing-git-into-svn.html

Eric

On Tue, Jul 10, 2018 at 8:30 AM Martin Sauer  wrote:

> Hello,
>
> I want to migrate my git project archive to subversion. In the internet
> I can't find only infos about migrate from subversion to git.
>
> Can you tell me how I can migrate my projects to svn?
>
> Thank your for your help.
>
> BR
>
> martin
>
>
>

Re: LDAP authenticate problem

[Eric Johnson]

The question relates to to either Apache, or the ActiveDirectory
configuration, not Subversion, from the looks of it.

The mailing lists for httpd will probably be able to give better advice
more quickly.

Eric.


On Mon, May 21, 2018 at 2:41 PM, Paul Nguyen 
wrote:

> I’m running SVN 1.9.3 (r1718519), on Ubuntu 16-04 with Server version:
> Apache/2.4.18 (Ubuntu).
>
> Problem is when a user failed 3 times with his password, the account
> doesn’t get locked but it keeps prompting. It looks like it authenticates
> against every single file in the path of the repo that user wants to access.
>
> The apache.conf:
>
>
> 
>
>   ServerName 
>
>   ErrorLog /var/log/svn/docs_LDAP_error.log
>
>   CustomLog /var/log/svn/docs_LDAP_access.log common
>
>   
>
> DAV svn
>
> SVNPath /var/svnrepo/docs
>
> ##LDAP
>
>  AuthName "docs Repo - Active Directory Authentication"
>
> AuthBasicProvider ldap
>
> AuthType Basic
>
> AuthLDAPGroupAttribute member
>
> AuthLDAPGroupAttributeIsDN On
>
> AuthLDAPURL "ldap://:389/cn=Users,dc=chp,
> dc=com?sAMAccountName?sub?(objectClass=*)"
>
> AuthLDAPBindDN "app_subvers...@chp.com"
>
> AuthLDAPBindPassword ""
>
> require valid-user
>
> ##
>
> RequestHeader edit Destination ^https: http: early
>
> AuthzSVNAccessFile /var/svnrepo/auth/docs-subdomain
>
> SetInputFilter DEFLATE
>
> SetOutputFilter DEFLATE
>
> SVNIndexXSLT /.chp/svnindex.xsl
>
>   
>
> 
>
> Is there a way to lock out an user account after 3 failed attempts as it's
> supposed to ?
>
> Thanks,
> Paul
>

Re: Subversion Exception during cleanup

[Eric Johnson]

Start with upgrading to a newer version of TortoiseSVN.

Eric.

On Thu, May 17, 2018 at 12:40 AM, Hartmut Leister 
wrote:

> I encountered the following exceptions (see below) in the mid of
> SVN-Cleanup.
>
> What I was doing:
> - SVN-merge via TortoiseSVN, stopped with Error due to SVN-lock
>   (small local changes separate from merged locations)
> - SVN cleanup via TortoiseSVN on locked folder -> exception
> - press [OK] -> next exception
> - press [OK]
> - trying cleanup again -> "Cleanup has successfully processed the
> following paths: ..."
>
> Best wishes
> Hartmut Leister
>
>
> ---
> Subversion Exception!
> ---
> Subversion encountered a serious problem.
> Please take the time to report this on the Subversion mailing list
> with as much information as possible about what
> you were trying to do.
> But please first search the mailing list archives for the error message
> to avoid reporting the same problem repeatedly.
> You can find the mailing list archives at
> http://subversion.apache.org/mailing-lists.html
>
> Subversion reported the following
> (you can copy the content of this dialog
> to the clipboard using Ctrl-C):
>
> In file
>  'D:\Development\SVN\Releases\TortoiseSVN-1.9.4\ext\
> subversion\subversion\libsvn_client\cleanup.c'
>  line 227: assertion failed (svn_dirent_is_absolute(dir_abspath))
> ---
> OK
> ---
>
> followed by
>
> ---
> TortoiseSVN
> ---
> Cleanup failed to process the following paths:
> E:\Projekte\ORS_Applications\ORSOFT_7_5_1
> sqlite[S5]: database is locked, executing statement 'PRAGMA
>  case_sensitive_like=1;PRAGMA synchronous=OFF;PRAGMA
>  recursive_triggers=ON;PRAGMA foreign_keys=OFF;PRAGMA locking_mode =
>  NORMAL;PRAGMA journal_mode = TRUNCATE;'
> Another process is blocking the working copy database, or the underlying
> filesystem does not support file locking; if the working copy is on a
> network filesystem, make sure file locking has been enabled on the file
> server.
> ---
> OK
> ---
>
>
> Version info
> TortoiseSVN 1.9.4, Build 27285 - 64 Bit , 2016/04/24 13:59:58
> Subversion 1.9.4, -release
> apr 1.5.2
> apr-util 1.5.4
> serf 1.3.8
> OpenSSL 1.0.2g  1 Mar 2016
> zlib 1.2.8
> SQLite 3.12.1
>
> --
>
> Hartmut Leister  
>
>
>

Re: Moving SVN from one server to another

[Eric Johnson]

It should be OK to use rsync, so long as the "old server" is not in use and
the repositories are not being modified while you're syncing them.

Then, I strongly recommend a dump and load on the new server.

Eric.

On Mon, Apr 23, 2018 at 3:19 PM, Paul Greene 
wrote:

> Hello,
>
> I need to move a subversion deployment from an ancient Redhat server to a
> new Centos7 server.
>
> The old subversion server is running version 1.4.6-1. The new server is
> running 1.7.14-11.
>
> There's 110 different repositories on the old server, so I'm looking for
> an efficient way to move all of the old repositories to the new server.
>
> The old server has its repositories under "/data/subversion", so I created
> the same folder and sub-folder on the new server.
>
> Is it possible to do an NFS share of the /data/subversion folder on the
> new server, mount that share on the old server and just "cp -R --preserve *
> " to the new server to keep the same permissions and ownership? Will all
> the repos work correctly if copied over in that way?
>
> I tried a test of a couple of repo folders and it seemed to copy over and
> keep all the correct permission/ownership settings, but I'm not sure if the
> repos will still work correctly without doing something additional to them.
>
> Thanks,
>
> PG
>

Re: Is svnadmin load affected by hooks?

[Eric Johnson]

Hi Bo,

On Thu, Mar 29, 2018 at 2:29 PM, Bo Berglund <bo.bergl...@gmail.com> wrote:

> On Thu, 29 Mar 2018 10:23:34 -0700, Eric Johnson <e...@tibco.com>
> wrote:
> >On Wed, Mar 28, 2018 at 8:17 PM, Bo Berglund <bo.bergl...@gmail.com>
> wrote:
> >
> >If you're dumping into an empty repository, that typically resets the
> >repository UUID to match that of the dump file. Changing the UUID will
> >break the sync.
>
> Gosh, that was unfortunate! I have just completed the local load
> operation for all repos. If the UUID will block the subsequent
> synchronize (which I have not come to yet but is next on my list),
> then this is also all in vain...
>
> But to be on the other side if I can use
> svnadmin setuid 
> to I get a fresh uuid on all of them, maybe that will make it work for
> sync after all?
>

Yes.

Eric.

Re: Is svnadmin load affected by hooks?

[Eric Johnson]

Hi Bo,


On Wed, Mar 28, 2018 at 8:17 PM, Bo Berglund  wrote:

> When I load a dump into an empty repo, will the operation be affected
> by the hooks I have already set up for svnsync?
>

If you're dumping into an empty repository, that typically resets the
repository UUID to match that of the dump file. Changing the UUID will
break the sync.


> I have created dumpfiles for all 9 repos I want to sync, and now I am
> about to load these into the repos I had prepared for sync when I
> discovered that network problems interfered.
>

svnadmin load takes the options "--use-pre-commit-hook" and
"--use-post-commit-hook". Assuming you're using your post-commit hook to
trigger the calls to sync, you could pass that flag. That seems weird to
me, though, in that such an approach would trigger a sync request per
loaded commit.

Eric.

Re: No longer get multiple icons

[Eric Johnson]

Hi Victor,

It sounds like you might be using TortoiseSVN. Most likely you'll get a
better answer asking people familiar with that project. This email list is
specifically for the core SVN functionality, not the GUI clients.

Eric.

On Fri, Mar 16, 2018 at 9:53 AM, Victor A. Wagner Jr. 
wrote:

> I've been using CVS and then when Subversion was doing well I
> switched.apparently from showing the log from a few things, I pretty
> much was switched over in 2007.  I've enjoyed using it until the most
> recent versionsboth Subversion and Windows10. someplace along the line,
> I quit getting icons with the green circle and white checkmark on them if
> the "folder" was all up to date.  So now, I have to select each and do a
> commit to find out if it's actually up to date.  This is time consuming as
> I have around 35 different repositories.  I don't recall reading about the
> "feature" being removed as I was doing the updated to Subversion, then
> again it certainly COULD be Windows10 .  It would be nice to have
> the screen identifying the repositories that need to be committed.
>
>

Re: regarding downloading subversion

[Eric Johnson]

Unfortunately, it is difficult to tell from your email what your question
is. And because of that, it is also difficult to tell if this is the right
forum for addressing your question.

Not meaning to be rude or dismissive, but can you provide more details? The
email says "not able to complete the download process". Download of what?
>From where? How did it fail? Depending on your answer, some other email
list might be more appropriate.

Eric.

On Thu, Feb 8, 2018 at 3:09 AM, nayama scariah  wrote:

> Good day sir,
> I tried to download Apache Subversion 1.9.7 for working on krc model in
> Davinci platform. But I am not able to complete the download process. After
> extract all the data from Zip file what is the next step for further
> proceedings and I tried to download Slik subversion also, which is also not
> working.
>
> Kindly please help me out with this
>
> Regards
>
> Nayama Valsa Scariah
>

Re: Hiding Subversion version number

[Eric Johnson]

Hiding the version information is but a piece of the puzzle. It won’t save
a server from a persistent attacker. However, hiding the server software,
and the software version, makes it harder for “drive-by” attackers to
discover that your server is vulnerable. They don’t generally want to spend
the time to test the universe of known compromises to server software, but
if they know they only need to test for vulnerabilities to Subversion
1.7.X, then you’ve got their attention.

Hiding that information slows the drive-by attackers down, much like having
a safe will do the same. In some cases the extra time nudges attackers
towards looking for easier targets.

Eric

On Dec 16, 2017, at 3:35 AM, Branko Čibej  wrote:

On 15.12.2017 20:10, Matt Simmons wrote:

Many documents relating to information security compliance require

blocking visible software version information.


Interesting documents. I'd have expected them to require all software to
be patched to fix all known security bugs. I thought the "security by
obscurity" mantra had been debunked, but apparently not ...

-- Brane

On Fri, Dec 15, 2017 at 10:46 AM Nico Kadel-Garcia >> wrote:


   Why would you want to hide this?


   On Fri, Dec 15, 2017 at 10:54 AM, Dave Huang >> wrote:

On Dec 15, 2017, at 9:15, Dhanushka Parakrama

   >>

wrote:



Hi All


Is there any configuration where i can hide  the subversion

   version details

.Please see copied image 


-- 

"Today, vegetables... Tomorrow, the world!"

Re: Recommended apr / openssl etc. library version for svn ?

[Eric Johnson]

I don't know if this helps, but I run Subversion on a Gentoo system, which
is constantly upgrading to newer versions of software. Gentoo does a really
good job of only marking stuff stable when it is actually stable. So if
Gentoo doesn't have openssl 1.1 in use, there's a really good reason.

This is what is currently "stable" on my Gentoo system running Subversion
(which is a few weeks old - minor updates might be available):
*Apache httpd 2.4.27
*Apache Serf(tm) 1.3.8
*APR 1.5.2
*APR-util 1.5.4
*APR iconv (not installed on my machine)
*Expat 2.2.1
*OpenSSL 1.0.2l
*PCRE 8.41
*SQLite 3.19.3
*ZLib 1.2.11

Specifically, in the case of openssl, I found this bug tracking all the
compatibility problems: https://bugs.gentoo.org/592438 . Seems like you
probably want to stay away from it.

Eric.

On Tue, Nov 21, 2017 at 7:11 AM, Cooke, Mark <
mark.co...@siemens-healthineers.com> wrote:

> Hello,
>
> Is there any support for building svn with OpenSSL 1.1.0 yet?  I did a
> search in the archives and only came up with Stefan's MaxSVN build which
> has so far excluded the update from 1.0.2 [1] but that was back in February?
>
> [1] https://svn.haxx.se/dev/archive-2017-02/0145.shtml
>
> I managed to build httpd with apr 1.6.2 and OpenSSL 1.1.0g (using `
> cvtdsp.pl -ossl11`) but the subversion build has 113 errors and I am
> wondering if this is worth persevering with?
>
> If not, is the MaxSVN dependency list about the best recommendation?
>
> *Apache httpd 2.4.23 (.29)
> *Apache Serf(tm) 1.3.9
> *APR 1.5.2 (1.6.3)
> *APR-util 1.5.4 (1.6.1)
> *APR iconv 1.2.1 (1.2.2)
> *Expat 2.2.0 (2.2.5)
> *OpenSSL 1.0.2j (.2m)
> *PCRE 8.39 (8.41)
> *SQLite 3.15.1 (amalgamation) (3.21)
> *ZLib 1.2.8 (1.2.11)
>
> ...subject to security updates of course (brackets show latest version at
> time of writing)!
>
> Thanks,
>
> ~ Mark C
>
>

Re: Subversion version 1.6.11 (r934486) package

[Eric Johnson]

Hi Fei,

On Fri, Sep 22, 2017 at 9:16 AM, Fei Peng  wrote:

> Hello,
>
> Can you please tell me where I can get Subversion version 1.6.11 (r934486)
> package? I need to setup a 1.6.11 server on centos7, then migrate our
> current svn 1.6.11 on centos5.6 to the 1.6.11 server on centos7. Then
> upgrade the svn 1.6.11 server on centos7 to the current version (1.9.7).
>

The recommended upgrade path would probably be different than what you
describe. Do an svnadmin dump on your current server, and import on your
new server, with whatever version of Subversion you're running there. If
you cannot take any down time, do the dump & load, then set up svnsync to
catch up and keep the two servers in sync. When you're ready to switch
over, you stop new commits to the existing server, make sure the sync
operations finish, then deactivate the syncing and turn your new server
liver. Maybe a minute of total down time.


>
>
> I am not sure if I can install svn 1.9.7 on centos7 and migrate my svn
> 1.6.1 directly to the 1.9.7 on centos7.
>

I believe so, if you follow the approach I outlined above. Caveat - I don't
run CentOS.

Eric.


>
>
> Any advice will be highly appreciated and thank you in advance!
>
>
>
> *Fei Peng*
>
>
>
> t: +1 519.620.7232 <(519)%20620-7232>
>
> m: +1 519.497.9917 <(519)%20497-9917>
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> *www.trustwave.com *
>
>
>

Re: Checksum mismatch still with 1.8.19

[Eric Johnson]

Does an svnadmin load, with the same dump file, work without errors, when
you load back into version 1.8.5?

How did you create the dump file? Did you use the incremental form with
deltas?

Eric.

On Tue, Aug 29, 2017 at 9:58 AM, Grant Drake 
wrote:

> Our current Subversion server is 1.8.5. We are trying to setup a
> replacement server, on which I have installed 1.8.19.
>
>
>
> The svnadmin load command on the 1.8.19 server for one of the repository
> dump files only comes up repeatedly with this error about 80% of the way
> through the revisions:
>
>
>
> svnadmin: E16: SHA1 of reps '-1 133 284 793
> a21e1fc00eb3e762b9b269b65b16a7bc ac7b8b00ada08b3e6bba37a0be206ad5faab70c1
> 6476-4zw/_a' and '-1 641 284 793 a21e1fc00eb3e762b9b269b65b16a7bc
> ac7b8b00ada08b3e6bba37a0be206ad5faab70c1 6476-4zw/_a' matches (
> ac7b8b00ada08b3e6bba37a0be206ad5faab70c1) but contents differ
>
> svnadmin: E160004: Filesystem is corrupt
>
> svnadmin: E200014: Checksum mismatch while reading representation:
>
>expected:  a21e1fc00eb3e762b9b269b65b16a7bc
>
>  actual:  ac1cc0244040d0134191ec8cec175e1f
>
>
>
> I have run svnadmin verify on the original server repo, it shows no
> indication of corruption.
>
>
>
> What can we do? Must we upgrade the original source server to 1.8.19 in
> order to produce a new dump file that can be loaded?
>
>
>
>
>
> --
>
> This e-mail, including accompanying communications and attachments, is
> strictly confidential and only for the intended recipient. Any retention,
> use or disclosure not expressly authorised by Markit is prohibited. This
> email is subject to all waivers and other terms at the following link:
> http://www.markit.com/en/about/legal/email-disclaimer.page
>
> Please visit http://www.markit.com/en/about/contact/contact-us.page for
> contact information on our offices worldwide.
>

Re: 【wait on line】weird question about svnsync

[Eric Johnson]

This could be for a number of reasons. Perhaps your original repository is
an older format? If that's the case, and your mirror is a newer format,
then the newer format could be packing and finding binary duplicates much
more effectively than is possible using the older format.

Eric.


On Thu, Jul 20, 2017 at 6:07 AM, Nico Kadel-Garcia  wrote:

> Better deduplicaton? And did you exclude old branches with bulky binaries
> in them?
>
> On Mon, Jun 26, 2017 at 7:07 AM, Dummy <3295285...@qq.com> wrote:
>
>> dear subversion:
>> I have a weird question about svnsync:
>> i svnsync gzrepos(centos 6.4-svn1.6.11) to gz-mirror1(centos 7-svn1.9.5),
>> when it was done successfully, i found that the mirror repo(gz-mirror1)
>> is more less than source repo(gzrepos) in sizes ,the source
>> repo(gzrepos) is *177G* while the mirror one(gz-mirror1)  is only *66G*
>> for example: revision:2012,it seems to be compressed
>> svnsync logs:
>>
>> however, the mirror repo(gz-mirror1)  seems OK, we can
>> access,checkout,show log etc.
>> i heard that subversion 1.9.5 has Optimized data format,but the gap is
>> too large。
>> I'm a little worried about the data，may i ask why?
>> best wish
>>
>
>

Re: [wait on line]about svnsync

[Eric Johnson]

As best I can tell, the problem is that your hook scripts end in ".sh". The
file name should just be "pre-revprop-change".

Eric.

On Thu, May 18, 2017 at 11:39 PM, Dummy <3295285...@qq.com> wrote:

> dear subversion:
> when i exec : svnsync init svn://192.168.5.32/CMMI-mirror
> http://192.168.9.222/CMMI
> i was given a error : please create a pre-revprop-change hook, but i
> already have one and it works by hand
> i tried many solutions,but they  are  not available
> so i need help o(╯□╰)o  , could you please  point out what the problem is?
>
> here is the problem:
>


3104F416@44AD4601.1C931E59
Description: Binary data

Re: On the subversion I have a question to confirm

[Eric Johnson]

It is a little bit difficult to follow your question.

Perhaps you can restate the question as a sequence of Subversion actions,
and a question about the result?

As a stab at your question, when a change is committed, all the preceding
changes are still available from the repository.

Eric.


On Fri, May 19, 2017 at 3:25 AM, shen...@snail.com 
wrote:

>
>
>
>
> *Hello there:On the subversion I have a question to confirm，
> that the historical version has been submitted inside, whether by modifying 
> the underlying file to modify the historical version of the content, hoping 
> to help answer this question, thank you.Snail
> 蜗牛数字 苏州蜗牛数字科技股份有限公司 沈磊/全球运维中心 TEL: +86(0512)67671313
> <+86%20512%206767%201313>*
>
> *MOB:13913112414*
>
> *FAX:+86(0512)67671231 <+86%20512%206767%201231> Email: shen...@snail.com
>  Add：苏州工业园区中新大道西171号 平台官网：www.snail.com
> *
>
> 企业官网：about.snail.com
>
> 请关注蜗牛新浪官方微博：http://weibo.com/woniushuzi
>
>
>
>
>
> 本邮件及其附件所载内容可能含有保密信息并受法律保护，任何人切勿传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。
> 若您误收本邮件，请通知发件人，并删除原始邮件、附件及其所有复本。
>
> This email (including any attachments) is confidential,
> may be legally privileged and is for the intended recipient
> only. Access, disclosure, copying, distribution, or
> reliance on any of it by anyone else
>
>  is prohibited. If you received this message in error, please contact the
> sender and destroy all copies of this email.
>

Re: Facing issues in Enable editing log messages.

[Eric Johnson]

The failures shown in your screenshot are due to authentication, and appear
to be unrelated to Subversion. It would appear that the csvn user is either
an invalid user or you have the wrong password.

Eric.

On Wed, May 17, 2017 at 3:26 AM, Ramamurthy, Manochitra <
mramamur...@intevaproducts.com> wrote:

> Hi Team,
>
>
>
> Greetings !
>
>
>
> I’m unsure whom to contact I found this mailing address when I do search
> for this issue.
>
>
>
> I have joined this organization INTEVA before few months and taking of
> SVN. I have query regarding Enable editing log messages in SVN which I have
> no clue on it. But just googling I followed below steps but no luck.
>
>
>
> · Created “pre-revprop-change” hook under hooks directory.
>
> · Added below script in it.
>
> ---SNIP---
>
> REPOS="$1"
>
> REV="$2"
>
> USER="$3"
>
> PROPNAME="$4"
>
> if [ "$PROPNAME" = "svn:log" ]; then exit 0; fi
>
> if [ "$PROPNAME" = "svn:date" ]; then exit 0; fi
>
> exit 1
>
> ---SNIP---
>
>
>
> Pasted from 
>
> · Executed this svn propset -r * revision no* --revprop svn:log
> new message *URL*
>
>
>
>
>
> Please assist me or point me to someone who can help me.
>
>
>
> Thanks,
>
> *Mano*
>
> +91 8046552670 <+91%2080%204655%202670>
>
> Available from 10am to 5pm IST
>
>
>
>
>

Re: so urgent

[Eric Johnson]

That is a very old version of the client. You probably want to upgrade your
client to something newer before you try anything else.

Eric

On May 11, 2017, at 10:36 PM, tina S.  wrote:

Hello,

i was working with the svn and tried to revert some files

then i started getting this error and right now i can not do anything with
my source

i repaired and re installed the software but no luck

please i need an urgent help with this issue

Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.11\ext\subversion\subversion\libsvn_subr\token.c'
line 51: internal malfunction

-- 
Best Regards
Tina S.

Re: File storage

[Eric Johnson]

Also, possible to have a Subversion repository accessible with a file:///
URL, rather than using an http(s):// or other URL.

Perhaps that is an answer to your question, in the sense that no "server"
is required? While that kind of arrangement might work for tracking
individual work, sharing a "repository" with other people may not work as
expected.

Unlike Git, the Subversion repository must be stored in a location other
than the Subversion working copy. That other location, however, need not be
on a separate server.

Eric.

On Wed, Mar 22, 2017 at 5:29 AM, Sagar Parekh 
wrote:

> Hi All,
>
> I wants to use client server model for storing the files.
> But do I need a physical server or files will be stored in SVN's servers.
>
> I want your server to store the files and my computer will be just client.
>
> Will that be possible with SVN? Any links for this?
>
> Regards,
> Sagar
>

Re: SVN log --revision "{2017-02-23T18:53Z}:{2017-02-24T02:46:15.225107Z}" not parsing date correctly?

[Eric Johnson]

That's an interesting one.

I don't know why you're seeing the behavior you're seeing. However, I can
tell you that relying on the date is probably a mistake. Instead, better to
capture the revision # for the repository, and log for revision #s after
the last one you got. There are scenarios in which the svn:date information
recorded with a revision need not appear in strict chronological order.
I've run into this after combining repositories with svn:load.

Also it is possible to either change an svn:date property (svnadmin propset
...), or remove it altogether. In other words, depending on what you allow
of the repository clients, the date is not a reliable indicator of "changed
since".

Eric.


On Fri, Feb 24, 2017 at 10:08 AM, Dane Kantner 
wrote:

> I'm running a script on a scheduled basis where each new iteration I'm
> essentially checking against a newer time from the last check-in, so if the
> last check-in was at 2017-02-23T18:51:15.175583Z the goal would be to add
> ticks to that after that in terms of the revision to retrieve everything
> after that last check-in time via the svn log command. Generally this is
> working great, but the actual results from the command aren't always
> consistent. Sometimes the return results will include stuff that's
> obviously before the provided start date. I initially was adding ticks,
> then I added a second, and now even in the below command I'm getting
> inconsistent results whereby it's returning something that's a full 20
> minutes before the command inputted... So I'm at a loss--is this a parsing
> error, is this date not really compliant (I believe it is...), etc.? I've
> tried consolidating the date format to just 2017-02-23T18:52Z etc as well
> and it doesn't matter.
>
> The exactly command (slightly redacted here) I'm running is:
>
> svn.exe log --non-interactive --trust-server-cert --username ""
> --password "*" --revision 
> "{2017-02-23T18:51:17Z}:{2017-02-24T02:46:15.225107Z}"
> --verbose --xml
> "https://AsXXX.4X.nett:443/svn/asi/br/synergyR1.48;
> "DOTNET/A/ExternalComponents" "DOTNET/A/Sequencer" "DOTNET/A/Synergy"
>
>
> and the resultant XML is:
> returning two items within that, the first of which should be there and
> one which is before the provided time:
>
>
>
> 
> 
> revision="54437">
> oooy
> 2017-02-23T18:51:15.175583Z
> 
> action="M"
>prop-mods="true"
>text-mods="false"
>kind="dir">/branches/SynergyR1.48/DOTNET/A/Synergy
> ...
> revision="54442">
> oooyb
> 2017-02-24T02:46:15.225107Z
>
>
> I've been manually running this command from windows on multiple machines
> w/ same result. I have latest tortoise client on at least 2 of the machines
> but SVN server itself is version 1.8.11r1643975. I don't see anything too
> obvious in the change log since that seems relevant to this though if it
> were a bug.
>
> So the time is 2017-02-23T18:51:15.175583Z ... I've tried changing the
> start time and the very specific point in start time at which it goes from
> including it here is {2017-02-23T19:06:02.41247Z} changing it one tick up
> to: {2017-02-23T19:06:02.41248Z}   ... That's roughly shy of exactly 15
> minutes after the actual checked time time.  What is going on here w/ this
> parsing?  Again to clarify though even the simpler format
> {2017-02-23T18:53Z} fails to properly parse as that includes the check-in
> when it shouldn't. I've also tried a simple end date/time and that doesn't
> affect the results.
>
>
> Anyone have any suggestions or what to try to track this down?  Given the
> time
>

Re: Checkout through link ignores rev parameter

[Eric Johnson]

What version of the Subversion client & server are you using?

Eric

On Mon, Jan 23, 2017 at 10:54 AM, Dalton, Bill (GE Energy Connections) <
bill.dal...@ge.com> wrote:

> We have projects which share some of the files in the subversion folders
> but not all.  So, those projects put their files into separate folders.
> One of the pairs of folders contains the actual files.  The other folder of
> the pair has subversion links which point to the actual files in the other
> folder.  This strategy seems to work with only one very important
> exception.  When  the folder with the links is checked out, the actual
> files always return the HEAD version, ignoring the “rev=” parameter.
>
>
>
> Specifically, there are two folder in Subversion whose paths are
> “trunk/firmware/cpu_fw/dia” and “trunk/firmware/cpu_fw_vx7/dia”.  Most of
> the files in the cpu_fw_vx7/dia folder (that is, all of the shared files)
> are links which point to the corresponding file in the cpu_fw/dia folder.
> If the cpu_fw_vx7/dia folder is updated with a “svn update -r 17905
> –non-interactive –force svnRepos/trunk/firmware/cpu_fw_vx7/dia” command,
> it will always fetch the HEAD revision, instead of the 17905 revision.
>
>
>

Re: post-commit hook

[Eric Johnson]

By any chance does the gmail account in question now have two factor
authentication turned on?

Eric

Sent from my iPad

> On Dec 11, 2016, at 6:21 PM, João M. S. Silva  
> wrote:
>
> [I'm not subscribed to the list, please CC me.]
>
> Hi,
>
> I have been using subversion-tools to send post-commit e-mails. I use
> the mailer.py and mailer.conf.example to create my own configuration
> file. This has worked for years.
>
> However, recently I get this error:
>
>   smtplib.SMTPException: SMTP AUTH extension not supported by server
>
> Searching for a solution, it seems we have to run "starttls" before
> "ehlo", but I don't think I can change that, the way I'm running it.
>
> I'm simply calling mailer.py with the correct configuration file. I
> checked if my configuration file was up to date (comparing with the one
> from the subversion-tools package) and it is.
>
> So, the problem should be inside subversion-tools, right?
>
> I'm sending the post-commit e-mail through Gmail, so maybe some recent
> change in Gmail's server could also be the culprit?
>
> Thanks.
>
> --
> João M. S. Silva

Re: Svn branching issue

[Eric Johnson]

On 11/7/16 10:10 AM, gyanendra ojha wrote:


Ok so u mean ..there is no way out for this..no solution

Maybe, maybe not. It isn't clear whether your concern is about losing 
history, or that Subversion doesn't let you rewrite history to reflect 
some arbitrary desired state.


Subversion won't lose history.

Eric.


On 7 Nov 2016 23:37, "Eric Johnson" <e...@tibco.com 
<mailto:e...@tibco.com>> wrote:


On 11/7/16 9:58 AM, gyanendra ojha wrote:

hi eric,

that is the issue, new branch created from old location is
having the old path in svn log,i want it to point it to newly
created branch path

for example there is svn old branch //depot/a/a.txt

now if i create branch //depot/b from old branch

it will have a.txt in b branch..but when i go to
//depot/b/a.txt and at GUI of SVN..do right click and select
show log option..it shows history of changes done in
a.txt but
in path section it still shows //depot/a/a.txt instead of
//depot/b/a.txt..now if old branch gets deleted..this history
will be irrelevant for me


As I said I in my previous response, you should review info on peg
& operative revisions.

Also, even if you delete //depot/a/ , the history of //depot/a
persists, it is just not accessible when "peg" revision is "HEAD".


requirement is to move a/a.txt to new location b/a.txt with
history retained and that history should have changes pointing
to new location b/a.txt not a/a.txt


With Subversion, you cannot have the history changes pointing to
the new location after your move, because that would not reflect
the actual history! That would be re-writing history as if folder
"a" never existed.

Eric.


i hope now u understand my issue

On Mon, Nov 7, 2016 at 10:42 PM, Eric Johnson <e...@tibco.com
<mailto:e...@tibco.com> <mailto:e...@tibco.com
<mailto:e...@tibco.com>>> wrote:


On 11/6/16 10:26 PM, gyanendra ojha wrote:


Hi,

I was assigned a task to move a branch or folder to
different
location in svn

Making sure that history of the old branch is retained
and not
lost

I was able to do it and history was showing in even
new branch

But my problem is that when i do svn log in new branch
location..it shows me path still of old branch


The old location is part of the history of the folder. As new
changes appear in the new location, those changes will
show the
new path. Older changes that happened in the older
location will
show the old path.

Perhaps you're using something other than the command line
client?
Perhaps the UI is making this confusing?

svn log has a "--stop-on-copy" option that will show you the
history of the changes only in the current location.

I want history for this new branch to change as per
new branch
path..so that even in case the old branch gets deleted..i
might be able to view the changes showing in svn log
by going
to the path

Subversion will not lose your older changes, even if you
delete
the old path. All that deleting the old path does is
remove the
reference to the contents for current and future versions
of the
parent folder. Older versions of the parent folder still
contain
the older version of the child folder.

You might benefit from understanding the difference
between the
"peg" and "operative" versions.

http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
<http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html>
   
<http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html

<http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html>>

Eric.

Re: Svn branching issue

[Eric Johnson]

On 11/7/16 9:58 AM, gyanendra ojha wrote:

hi eric,

that is the issue, new branch created from old location is
having the old path in svn log,i want it to point it to newly
created branch path

for example there is svn old branch //depot/a/a.txt

now if i create branch //depot/b from old branch

it will have a.txt in b branch..but when i go to
//depot/b/a.txt and at GUI of SVN..do right click and select
show log option..it shows history of changes done in a.txt but
in path section it still shows //depot/a/a.txt instead of
//depot/b/a.txt..now if old branch gets deleted..this history
will be irrelevant for me


As I said I in my previous response, you should review info on peg & 
operative revisions.


Also, even if you delete //depot/a/ , the history of //depot/a persists, 
it is just not accessible when "peg" revision is "HEAD".


requirement is to move a/a.txt to new location b/a.txt with
history retained and that history should have changes pointing
to new location b/a.txt not a/a.txt


With Subversion, you cannot have the history changes pointing to the new 
location after your move, because that would not reflect the actual 
history! That would be re-writing history as if folder "a" never existed.


Eric.


i hope now u understand my issue

On Mon, Nov 7, 2016 at 10:42 PM, Eric Johnson <e...@tibco.com 
<mailto:e...@tibco.com>> wrote:



On 11/6/16 10:26 PM, gyanendra ojha wrote:


Hi,

I was assigned a task to move a branch or folder to different
location in svn

Making sure that history of the old branch is retained and not
lost

I was able to do it and history was showing in even new branch

But my problem is that when i do svn log in new branch
location..it shows me path still of old branch


The old location is part of the history of the folder. As new
changes appear in the new location, those changes will show the
new path. Older changes that happened in the older location will
show the old path.

Perhaps you're using something other than the command line client?
Perhaps the UI is making this confusing?

svn log has a "--stop-on-copy" option that will show you the
history of the changes only in the current location.

I want history for this new branch to change as per new branch
path..so that even in case the old branch gets deleted..i
might be able to view the changes showing in svn log by going
to the path

Subversion will not lose your older changes, even if you delete
the old path. All that deleting the old path does is remove the
reference to the contents for current and future versions of the
parent folder. Older versions of the parent folder still contain
the older version of the child folder.

You might benefit from understanding the difference between the
"peg" and "operative" versions.

http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
<http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html>

Eric.

Re: Svn branching issue

[Eric Johnson]

On 11/6/16 10:26 PM, gyanendra ojha wrote:


Hi,

I was assigned a task to move a branch or folder to different location 
in svn


Making sure that history of the old branch is retained and not lost

I was able to do it and history was showing in even new branch

But my problem is that when i do svn log in new branch location..it 
shows me path still of old branch




The old location is part of the history of the folder. As new changes 
appear in the new location, those changes will show the new path. Older 
changes that happened in the older location will show the old path.


Perhaps you're using something other than the command line client? 
Perhaps the UI is making this confusing?


svn log has a "--stop-on-copy" option that will show you the history of 
the changes only in the current location.


I want history for this new branch to change as per new branch 
path..so that even in case the old branch gets deleted..i might be 
able to view the changes showing in svn log by going to the path


Subversion will not lose your older changes, even if you delete the old 
path. All that deleting the old path does is remove the reference to the 
contents for current and future versions of the parent folder. Older 
versions of the parent folder still contain the older version of the 
child folder.


You might benefit from understanding the difference between the "peg" 
and "operative" versions.


http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html

Eric.

Re: SVN Properties

[Eric Johnson]

Hi Amad,

On 11/1/16 1:48 PM, CM Analyst wrote:

Eric,

Thank you for your response.

Actually, we do copy executables to a "release" directory in SVN.

However, for that to happen, the release content has to be defined in 
advance, completed the formal test cycle.
You could have another folder which is just "Pending RC". EXEs could 
then be moved from there to the destination


For some stakeholders, that's too late. Our challenge is really about 
how to determine release content.
I think Subversion properties don't get you there. Subversion properties 
speak to properties of the thing they're assigned to, where those 
properties are about the folder or file, not about what external systems 
/ people think of the folder / file. That's why "mimetype" is a perfect 
versioned property - it is a property about the file itself.


Why not have a version-controlled file which serves the purpose of 
identifying release content?


They want the ability to "see" (determine the eligibility of an .exe) 
beforehand: after coding and testing is done but before SW is copied 
to the 'release' directory.


My thought was to see if I can create some naming scheme by which to 
tie disparate components together using the property feature.


Perhaps that's not possible.
The properties are not the same as a "tagging" mechanism that you might 
find in other contexts.


Eric.




On Tuesday, November 1, 2016 2:36 PM, Eric Johnson <e...@tibco.com> wrote:


Hi Amad


On 11/1/16 10:26 AM, CM Analyst wrote:
> Hello,
> In our environment, there is a need to identify one or more set of
> files with a custom attribute. I expect SVN properties is the way to go?
> For a given set of .exes, I want to attach an attribute using the SVN
> property called "RC: Release Candidate".
> My questions:
> 1) Is this approach a recommended use for the SVN's property feature?
While there is nothing wrong with this use, given #2, it doesn't seem
like a particularly useful path.

Also, contrary to the apparent purpose of your proposed label, the label
will stick to the file even as you modify it. Which means that an update
to the EXE, would still be marked "RC: Release Candidate", and unless
you took an extra step in order to clear that setting. Since that step
could be forgotten, unless automated, it seems like a less-than-robust
mechanism.

Why not copy the exe to a "Release Candidate" folder in SVN?
> 2) Is there a way to search to later retrieve all .exes with the given
> property?
No. Also unclear whether you want to do this only for "latest", but also
for "over time". If you want to do it over time, that means exhaustively
searching through older releases.

> In my testing so far, I created:
> $ svn propset Released "This SW component is available for release." foo
> property 'Released' set on 'foo'
> $ svn proplist foo
> Properties on 'foo':
> Released
> svn:mime-type
> However, I was not able to then search and locate the file by its
> property.

Exactly.

> 3) What is a better way to indicate a given status/attribute on a set
> of files?

See my suggestion above about copying into a known folder. Would that
satisfy your requirements?

Eric.

>
> Amad

Re: SVN Properties

[Eric Johnson]

Hi Amad


On 11/1/16 10:26 AM, CM Analyst wrote:

Hello,
In our environment, there is a need to identify one or more set of 
files with a custom attribute. I expect SVN properties is the way to go?
For a given set of .exes, I want to attach an attribute using the SVN 
property called "RC: Release Candidate".

My questions:
1) Is this approach a recommended use for the SVN's property feature?
While there is nothing wrong with this use, given #2, it doesn't seem 
like a particularly useful path.


Also, contrary to the apparent purpose of your proposed label, the label 
will stick to the file even as you modify it. Which means that an update 
to the EXE, would still be marked "RC: Release Candidate", and unless 
you took an extra step in order to clear that setting. Since that step 
could be forgotten, unless automated, it seems like a less-than-robust 
mechanism.


Why not copy the exe to a "Release Candidate" folder in SVN?
2) Is there a way to search to later retrieve all .exes with the given 
property?
No. Also unclear whether you want to do this only for "latest", but also 
for "over time". If you want to do it over time, that means exhaustively 
searching through older releases.



In my testing so far, I created:
$ svn propset Released "This SW component is available for release." foo
property 'Released' set on 'foo'
$ svn proplist foo
Properties on 'foo':
Released
svn:mime-type
However, I was not able to then search and locate the file by its 
property.


Exactly.

3) What is a better way to indicate a given status/attribute on a set 
of files?


See my suggestion above about copying into a known folder. Would that 
satisfy your requirements?


Eric.


Amad

Seeing very slow performance with svnadmin verify

[Eric Johnson]

Using: svnadmin --version
svnadmin, version 1.9.4 (r1740329)

The first time I ran into this, I simply added the -M option. Since the 
default is reported just "16", I added "-M 384", and noticed a 
significant speed bump. However, I've got a repository where even this 
big jump didn't fix the performance problems. Current behavior is to 
appear to pause significantly, then report two versions verified. The 
pause lasts on the order of thirty seconds.


Since I have on the order of 230,000 additional commits to check, I'm 
looking at 39 days before my repository finishes verifying. That's not 
really acceptable.


Any suggestions? Am I doing something wrong?

Thanks!

Eric.

Re: History split after server-side mkdir/mv

[Eric Johnson]

On 10/27/16 7:04 AM, Dario Niedermann wrote:

I have a repository I had made in a pinch, without any directory
structure, just adding files to the root.

When the time came to add some method to the madness, I created
the 3 canonical directories, then moved (server-side) all files to
'trunk/'. Now, when I issue `svn log' in my freshly checked-out
working copy, I face the following situation:

*  'trunk/' only remembers revisions since when it was created;


I think your example will be easier to follow if you provide more 
concrete details, such as the specific log commands you're issuing.


However, without further information, it sounds like Subversion is 
functioning as designed. Namely, that in Subversion, a folder has 
history just like a file. So if you ask for the history of trunk, you 
can only find out the history of the folder back to its birth.


*  the single files within 'trunk/' remember and show their full
history;

*  when I `cd' to the working copy's "root" ('trunk/..') I see
everything: from 1 to HEAD, including all changes to 'trunk/'.

Now, since no history was lost, this is not a real problem. I'd just
like, for 'trunk/' (i.e.: when I'm in 'trunk/' and issue `svn log') to
see everything back to revision 1. So I guess the question is: is there
a way to tell 'trunk/' that it also "owns" the repository root history
up to its birth?


I don't believe there's any good way to do what you want without 
recreating the history of your repository. You might be able to achieve 
what you want by doing an svnadmin dump & load, where you load to a 
sub-directory trunk", then relocate everything buried a level down 
(trunk/trunk/...) back into the top-level trunk folder.


Eric.



Thanks for your comments,
DN

Re: Cannot add files due to hierarchical RDC svn:auto-props when matching rules merge properties between text and binary file types

[Eric Johnson]

Your constraints, as currently specified, seem to require actual logic

Thoughts follow your email.

On 10/12/16 1:44 PM, Rob Hofer wrote:
We have a rather common use case where we have an svn:auto-props rule 
set globally (set on root of repository) to define source code files 
as text based, but also have some files provided by 3rd parties which 
compress or encrypt similar files with the same file extension (which 
we have no control over), and hence we want to set an svn:auto-props 
rule locally on those directories to make those files binary type. But 
the hierarchical svn:auto-props rules add properties from multiple 
definitions of the same match filter (*.v), and result is a 
conflicting set of properties that block the add at the client 
(eol-style with mime-type=octet-stream).


For example, a binary and text based Verilog file (*.v):
%> file binary.v
binary.v: gzip compressed data, was "binary.v", from Unix, last 
modified: Mon Feb 18 19:44:25 2013, max compression

%> file text.v
text.v: ASCII text

The RDC auto-props for this directory shows these Verilog and VHDL 
types (local directory expects binary types, global are source-code 
text files).

%> svn propget svn:auto-props --show-inherited-props .
http://crsvn/gsadc - *.v  = svn:eol-style=LF;svn:keywords=Id 
Revision Date Author URL;svn:mime-type=text/x-verilog

. - *.v   = svn:needs-lock;svn:mime-type=application/octet-stream

Adding the files to SVN control fails, unless --no-auto-props is used 
(undesirable work around):

%> svn add binary.v
svn: E29: Can't set 'svn:eol-style': file '/module/lay/binary.v' 
has binary mime type property

%> svn add --no-auto-props binary.v
A  (bin)  binary.v
%> svn add text.v
svn: E29: Can't set 'svn:eol-style': file '/module/lay/text.v' has 
binary mime type property

%> svn add --no-auto-props text.v
A text.v

Subversion auto-detects the binary file and at least sets the 
mime-type, but other properties are missing because --no-auto-props is 
the only way to add the files without error.

%> svn proplist -v binary.v
Properties on 'binary.v':
  svn:mime-type
application/octet-stream
%> svn proplist -v text.v

%> svn --version
svn, version 1.9.4 (r1740329)
   compiled May 18 2016, 12:05:49 on x86_64-unknown-linux-gnu

(Incidentally, the commit will fail because our hook is checking these 
svn:auto-props rules and the file must match the binary rules or the 
text rule, based on the mime-type). So the only way today to add these 
files to SVN is to use --no-auto-props on add, and go into the server 
and disable the pre-commit hook during the commit, then put the 
pre-commit hook back.  Since a pre-commit hook is the only way to 
enforce the use of auto-props correctly, disabling the hook is not an 
optimal solution. Once added to SVN, the issue never comes up again 
because the properties do not change, and the pre-commit hook checks 
the modifications on future commits based upon the mime-type (binary 
or text rules). The issue is only during the initial add to SVN due to 
conflicting properties being applied to the file based on how the 
svn:auto-props definitions are being interpreted.


Proposed solution:
1. Make lower level svn:auto-props rules completely override upstream 
ones, rather than additively merging properties, for rules with same 
exact match filter (local *.v redefines upstream *.v completely).
2. Make SVN ignore properties such as eol-style and keywords when the 
mime-type is a binary type rather than issue a fatal error to the 
user/client (warning instead that some properties are being ignored).
3. Provide a subtractive property rule to undo an upstream property. 
E.g., svn:eol-style=none, or svn:keyword=none, such that a lower level 
rule can unset a property defined upstream (and make 
svn:eol-style=none behave same as if svn:eol-style was not applied at 
all).


Note: Before RDC svn:auto-props (pre 1.8), this use case required 
having two entries in the ~/.subversion/config, with one always 
commented out. When encountering one type or the other (text or 
binary), user would have to uncomment/comment the proper auto-props 
rule in their config file before the add, and then change their config 
back for the normal case. This was very unwieldly and required careful 
synchronization of all user runtime config files and hook scripts and 
manual intervention by the user during adds.  Hierarchical RDC 
properties should eliminate this problem, but it falls a little short 
because of how hierarchical RDC svn:auto-props rules merge mutually 
exclusive properties together. I believe this is very similar to 
multiple matches in the ~/.subversion/config runtime file, for example 
a *.v rule and a *-rtl.v rule could collide, except now it is possible 
to have the very same rule filter (*.v) defined in more than one 
location in the subversion hierarchy. See proposed solution #1 as my 
desired behavior from the SVN client.



Only a few options I see:

 - different 

Re: Implementing the Lock->Edit->Unlock cycle

[Eric Johnson]

On 9/29/16 4:58 AM, Anton Shepelev wrote:


Thanks to everybody for their replies.

Eric Johnson to Anton Shepelev:



"svn update" is your friend. Just  encourage  users
to do updates before they start editing.

Is  there no protection against an oblivious users's
losing a day's work merely because he forgot to  up-
date  his  working  copy,  which was obsolete beyond
merging?
Your best protection against this problem - which can happen with any 
version control system, is to keep developers updating and committing 
regularly. A developer who goes off in a corner for two weeks, then 
produces a massive change can disrupt under any system. The "exclusive 
lock" behavior of VSS and others prevents some aspects of that, but not 
others. Reminding your team to both update and commit regularly will 
probably solve the problem. For a similar reason, long-term branches can 
be quite tricky to manage.



Also, the lock-before-edit approach doesn't actual-
ly solve the problem of making sure users have  the
latest.   My  recollection  from using VSS was that
integration problems showed up more frequently, not
less.   I  think  this was from the illusion that I
have the latest version of the file I want to  edit
(since  I  got  the lock), so my files are probably
all going to be consistent.

VSS guarantees that you are editing the latest  ver-
sion  of  the  file, unless, of course, you have ex-
plicitly overriden the readonly attribute.  The oth-
er files, both dependent and depending, may be obso-
lete though.
Exactly. My point was merely that from my recollection, the switch from 
VSS to Subversion, counter-intuitively, led to fewer conflicts, all 
easier to resolve, not more.



I suspect you could tie yourself up into knots try-
ing  to  write hook scripts that accomplish some of
what you want, ->

I hope hooks are not that hard...


In principle, they're quite straightforward to write the first time. It 
is my experience that once you have a server running in production, 
changing the hook scripts gets tricky fast. You don't want to disrupt 
people with downtime, you need to test them, and weird corner cases 
emerge. Especially as the number of repositories you support goes up, 
and clients ask for different behavior across the repositories.


One way to avoid some of those problems - use / implement "web" hooks, 
where the post-commit or pre-commit logic lies off the server, and can 
be maintained independently of the server itself.



-> but by the time you get them  working  just  the
way  you  think you want them, you'll discover that
you probably don't want them that way.

Maybe, but I am under peer pressure, and TFS is  the
alternative,  and  I think we still need it at least
for "binary" files such as  MS  Word  documents.   I
wish  we  maintained documentaion in Texinfo, LaTeX,
of Troff, but am helpless in this regard.


Yes, for stand-alone binary files like MS Word docs, the Subversion 
locks are perfectly fine. The challenges with locks emerge when applied 
to documents like source code - where the files are inter-related. My 
suggestion - trust in Subversion for text files, and only use locks for 
frequently changing binaries.


Eric.

Re: Migrating old format repositories (format 4), running into bad line endings

[Eric Johnson]

Thanks for the reply.

On 8/22/16 5:25 PM, Daniel Shahaf wrote:

Eric Johnson wrote on Mon, Aug 22, 2016 at 14:29:47 -0700:

  * // move original repo out of the way, move new copy into position.

At the comma you should restart the server to flush caches:

 
http://mail-archives.apache.org/mod_mbox/subversion-users/201606.mbox/%3c20160609125706.GA4020@tarsus.local2%3e


Yes, I was simplifying a little in my pseudo-code, because after I stop 
the server, I want to do another sync, in case additional changes come 
in during the verify and pack steps.



Is there any particular reason that the "dump/load" process doesn't fix the
line-endings? Shouldn't it?

'load' could transform CRs, yes, but that might need to be optional to
keep the "verbatim round-trip" possibility.


Why have the --bypass-prop-validation option?
Why not just fix the line endings? As it is now, the dump-load process is
effectively broken, because I have one of two seemingly poor choices: I can
either "bypass validation" (that sounds bad), or I simply keep the old
format.

"Bypass" just means the existing values in the dumpfile will be
used verbatim.  Using this option makes the loaded repository be in the
same situation of the original 1.4 repository: a high-level invariant
("svn:* uses LF") does not hold, but the lower-level data format
invariants do hold.  In short, if you use this option you're postponing
the problem but not making your situation any worse.

Cheers,

Daniel

P.S. Feel free to file an issue about making 'load' transform CR in
svn:* nodeprops and revprops pointing to this thread.

I've filed https://issues.apache.org/jira/browse/SVN-4650

Thanks so much.
Eric.

Re: Migrating old format repositories (format 4), running into bad line endings

[Eric Johnson]

Hi Mark,

On 8/22/16 2:06 PM, Mark Phippard wrote:
On Mon, Aug 22, 2016 at 2:11 PM, Eric Johnson <e...@tibco.com 
<mailto:e...@tibco.com>> wrote:


So I wrote myself a tool to go through all commit comments, and
verify that no "CRs" appear in the svn:log entry. If I find them,
I rewrite the log entry. That way, I can clean up existing
repositories.

However, I ran into a surprise. CR characters have also snuck into
the svn:ignore property, which is /not/ a revprop, and cannot be
fixed by any of the tools available.

I've seen that other people recommend editing the dump file
directly, but that makes me quite nervous, especially on an 8MB
dump file. Hoping there's a better way.


Have you tried creating a new repository with the format you want and 
then use svnsync to sync the data to it?  I seem to recall that 
svnsync will fix the line endings as it syncs the log entries.  I 
could be wrong though because I see that svnsync has 
a --source-prop-encoding option that we added for fixing non UTF8 log 
messages.  So it is possible I am confusing with that option.  I would 
try it though since it is a a simple method to use.


I did just try this - svnsync does fix up the line ending problem. Even 
reports a nice summary at the end of what it did. So that's promising!


So it seems like a sync-based equivalent to dump / load, in order to 
migrate from one repo format to another looks something like this:


 * svnadmin create ... // create target repo
 * // enable revprop changes
 * svnsync init ...
 * svnsync sync
 * svnadmin pack
 * svnadmin verify
 * // remove revprop change script
 * // remove all the props on revision 0
 * // copy over all the hooks from the original repo
 * svnadmin setuuid ... // set the uuid of the new repository to the
   same as the old.
 * // move original repo out of the way, move new copy into position.

Is there some utility somewhere that does all of the above? I can go 
change my script to use the above approach instead of dump/load, but it 
is annoying


Is there any particular reason that the "dump/load" process doesn't fix 
the line-endings? Shouldn't it? Why have the --bypass-prop-validation 
option? Why not just fix the line endings? As it is now, the dump-load 
process is effectively broken, because I have one of two seemingly poor 
choices: I can either "bypass validation" (that sounds bad), or I simply 
keep the old format.


Eric.


--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Migrating old format repositories (format 4), running into bad line endings

[Eric Johnson]

So I wrote myself a tool to go through all commit comments, and verify that
no "CRs" appear in the svn:log entry. If I find them, I rewrite the log
entry. That way, I can clean up existing repositories.

However, I ran into a surprise. CR characters have also snuck into the
svn:ignore property, which is *not* a revprop, and cannot be fixed by any
of the tools available.

I've seen that other people recommend editing the dump file directly, but
that makes me quite nervous, especially on an 8MB dump file. Hoping there's
a better way.

Eric.

Re: securing of correct transmit

[Eric Johnson]

Hi Lars,

On 7/22/16 1:56 AM, Krueger, Lars (CQSE) wrote:

Hello together,
I need to know how SVN ensures that each item (comminting or 
updateing) is correctly transmitted from/ to a repository. If I use 
‘svn info’ command I can see a ‘Checksum’ for a file. Do you use this 
Checksum?


I have not examined the code. I can say, however, in the years that I've 
been lurking on this list, I've *never* seen anyone report an issue with 
a file being corrupted in transit to the server. I assume that is 
because the answer to your question is emphatically, "yes".


Of course, it is open source, so you can go look at the code. I was 
curious whether I could find it. This seems like the right file. I see 
references to "checksum" in their, so that's promising.

https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_client/commit.c

It is worth noting that you can turn on the svn:eol-style property 
(http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.ref)- 
which may mean that the checksum of the file in the repository will not 
match the checksum in your working copy.


Of course, you might also use a tool like OWASP ZAP as a proxy between 
an HTTP client and an HTTP server, and mess with the packets being 
passed between the client and the server, and see what happens.
It’s important to know, because we must validate your used tools to 
ensure that your Software is built correctly. Currently we use SVN 
1.8.11.
Looks like current version of Subversion 1.8.X is 1.8.16. If you want it 
to be the most correct, perhaps upgrade?


Eric.

mit freundlichen Grüßen/ with best regards
*Lars Krüger*

Embedded Softwareentwicklung
*Carmeq GmbH
*Carnotstr. 4
D-10587 Berlin
Mobil: +49 172 5892291(BIK: 266)
E-Mail: _lars.krueger@carmeq.com_ 
Internet: _www.carmeq.com_ 

Carmeq GmbH, Sitz / Domicile: Berlin, Registergericht / Court of 
Registry: Amtsgericht Berlin-Charlottenburg, HRB Nr./ Commercial 
Register No.: 86104, Geschäftsführer / Management Board: Peter 
Behrendt (Sprecher / Chairman), Michael Dinné
_Wichtiger Hinweis:_ Die vorgenannten Angaben werden jeder E-Mail 
automatisch hinzugefügt und lassen keine Rückschlüsse auf den 
Rechtscharakter der E-Mail zu.
_Important Notice:_ The above information is automatically added to 
this e-mail. This addition does not constitute a representation that 
the content of this e-mail is legally relevant and/or intended to be 
legally binding upon Carmeq GmbH.
Diese E-Mail und etwaige Anlagen können Geschäftsgeheimnisse oder 
sonstige vertrauliche Informationen enthalten. Sollten Sie diese 
E-Mail irrtümlich erhalten haben, ist Ihnen dieser Umstand hiermit 
bekannt. Bitte benachrichtigen Sie in diesem Fall umgehend den 
Absender und löschen Sie diese E-Mail einschließlich etwaiger Anlagen 
auf irreversible Art und Weise von Ihrem System. Diese E-Mail und 
etwaige Anlagen dürfen im Fall der irrtümlichen Adressierung auch 
nicht kopiert, an Dritte weitergegeben oder anderweitig missbräuchlich 
verwendet werden. Vielen Dank!
This email could contain confidential or privileged material. 
Therefore, the information transmitted by this email is intended only 
for specific persons or entities. If you received this email as a 
result of an error, please contact the sender immediately and delete 
the email from your system irreversibly. In this case, any copying, 
dissemination, retransmission, review, or other use of this email is 
strictly prohibited. Thank you very much!

Re: Component mangement and Subversion

[Eric Johnson]

This might seem a little off topic, and a long read, but might be useful 
for thinking about your problem:


https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.1g117atv5

Unfortunately, the answer you seek probably depends a little bit on what 
language you're working in, because different languages bring different 
tool kits to the table.


The dependency resolution problem usually ends up being tied to a 
particular build system, because the build system designers feel like 
they need to own the problem. Would be great if it was instead generally 
decoupled.


In any case, it is probably a bad idea to combine built artifacts of any 
sort with your source code tree. They tend to get in the way - taking 
longer to download a working copy, changing frequently, and possibly 
taking up lots of space. Combining external source code in your source 
build tree, via any means (such as svn:externals), is probably just 
fine, so long as the external source does not swamp the size of the 
local code.


Eric.

On 6/17/16 8:39 AM, Ignacio González (Eliop) wrote:

Hello.

I'm looking for examples on how to use Subversion efficiently in the 
context of component management.


We develop some products that we have to adapt to different markets. 
Some of the features are common, some are partially common, and some 
are unique for each market. Sounds like the definition of product 
variants, doesn't it.


We decided some time ago to use more and more a component approach for 
those software products, in order to maximize their reutilization in 
different variants, and to minimize the typical maintenance problems 
of fixing / enhancing / modifying common and non-common parts of the 
software.


Now we are using (abusing?) svn:external across different branches of 
our product variants, but we are afraid of escalating problems when we 
have even more variants, more products and more systems of products.


So I have researched a little (read: I have used Google) and I have 
stumbled upon three different approaches to the problem:


1) Yes, do use svn:externals! (with some structure and planning 
ahead). This is the approach proposed by John Martin in Reusable 
Component Management Through the Use of Subversion Externals ( 
http://www.bcs.org/upload/pdf/reusable-component-mgt-jmartin0708.pdf 
). It's perhaps a bit dated, but it presents several good ideas, I think.


2) Well, you'd better use something outside Subversion to do the real 
component management (a --possibly versioned-- file, a database...), 
and, at most, use some kind of script or the like to maintain a set of 
svn:external properties in the repository. This is the advice that my 
admired Stefan Sperling gave in this forum some time ago ( 
http://svn.haxx.se/users/archive-2010-11/0097.shtml )


3) Please, use our specialised tool for modelling and managing your 
product line and regard Subversion only as a revision control system 
to deal with later


I’m tempted to follow Stefan’s advice, but I would be grateful to have 
more specific examples on how others are implementing it (if any), or 
how others are using John’s solution, or if there are other possible 
approaches (examples, articles, links, even products) that could help me.


Thank you very much for your time.

--
Saludos / regards
Ignacio G. T.

Re: SVN

[Eric Johnson]

On 5/27/16 12:57 PM, Joseph Bruni wrote:


On May 26, 2016, at 10:09 PM, PERRY JENNINGS 
 wrote:


Family Dollar has implemented SVN and about sixty percent of projects 
within the organization currently uses this repository to maintain 
source code for object-oriented applications. However, the remaining 
forty percent of source code within the organization cannot use SVN 
because the code is for *non-object-oriented* applications ;


Terminology is confusing me here. Object-oriented code has nothing to do 
with version control. Is what you really mean that you work with tools 
that deal with either monolithic project files, or smaller but opaque 
binary files?


hence a single file, not a project needs to be checked in and out of 
the repository.  So my question is: Are you aware of a client that 
could be used to checkout and checkin a single file to the SVN 
repository and maintain the version number of the source code that is 
checked in?   If not, do you know if SVN has the single file checkout 
and checkin feature?


As a previous poster has mentioned, Subversion has "lock" functionality, 
so you can signal to people that changes are pending.


We do the same thing for the database SQL scripts, stored procedure 
code, and various one-off Perl programs. Source control systems like 
SVN (or Git) don't really lend themselves directly to this type of object.
Why would you say that? I've used Subversion for all of the above. Works 
great. I'd be curious what issues you've run into?
We do use SVN, but layered a lot of process on top of it to keep 
ourselves somewhat sane.
That's true of any source control system. You still need to manage the 
people and the workflows. Version control tools just make it easier to 
manage the shared built artifacts.


I can imagine someone could build a nice single-file revision control 
system on top of SVN, but it would require a new type of client that 
would hide the directory revisioning from the user.
An alternate tool like Perforce can be used, as I recall, to actively 
prevent people from making changes to a file when it isn't "checked 
out". This is otherwise known as "pessimistic locking." If your user 
needs require pessimistic locking, then you should use a tool that does 
it. Probably not a good idea to squeeze everything into Subversion, if 
that's the case.


Eric.

Re: LDAP Usage Question

[Eric Johnson]

We scan our LDAP server, and generate group information from that, and 
then apply that to our version control servers.


Eric.

On 5/24/16 12:51 AM, Dariusz Nowak wrote:


Hello,


I'm new in subversion world and tried to research something yesterday 
- without success, so decided to post here. My question is related to 
authentication using LDAP.



My scenario is that I will require 2 auth methods (passwd + ldap) all 
of services (like Jenkins) will use passwd + authz and all of "humans" 
will use their AD accounts.  I found really useful option in config 
aliasses however got small problem applying to LDAP. And my question is:



Can I create aliasses for LDAP groups ? I want in my LDAP AUTH file to 
have something like:


[aliases]

mygroup = CN=PATH,DN=TO,DN=LDAP,DN=GROUP


[/]

@mygroup = r


So I'm allowing for example every User object in my ldap tree to 
access, but later limiting it like that ... this is how our current 
setup works (a lot of hardcoded user/groups in auth/passwd files and 
[/path/to/repo] = group1 = r, group2 = rw etc.



Trying to mimic that with LDAP


Regards

D

Re: New Mac Subversion Client

[Eric Johnson]

On 5/20/16 6:27 AM, Jonathan Guy wrote:

OK just to clarify.
The app currently has "built-in" libraries for subversion 1.6.23, 1.7.22, 
1.8.15, and 1.9.3.
It does not use any installed version you may have.
The libraries are loaded dynamically into their own namespace on demand meaning 
all libraries can be loaded at the same time.
If your working copies are derived from Subversion 1.6 -> 1.9 then you can work 
with them all simultaneously.


That's a neat trick!

Eric

Re: Blank lines

[Eric Johnson]

Hi Darek,

On 5/4/16 4:43 AM, Dariusz Staniak wrote:

How can I force
svn status
not to indicate files with added/removed blank lines as modified?
You can't. Subversion has to treat all changes to files as relevant. 
Consider something like Markdown - an extra blank line means a paragraph 
break. In code, where inserting a blank line might help readability.


I'm fighting with this all day today and I cannot find any help.


If this is due to co-workers who fight over tabs-vs-spaces, and making 
sure that blank lines are also empty, for that, your team should agree 
on a convention, and use a tool to enforce it consistently. Recent IDEs 
typically have this ability built in, so it is a mere matter of clicking 
a button to get code to conform to white space rules. Or you can use a 
stand-alone tool that runs from the command line.


You could also have Subversion enforce pre-commit rules that enforce 
conformance to use of particular white space rules. This will prevent 
people from making changes, but perhaps also make them very unhappy. So 
tread carefully.

I've already changed diff-cmd and diff3-cmd to ignore blank lines, but
I still see these files as modified which gives me a jungle of changes
that I don't want to see.
Sounds like you like the command line. If you also use IDEs, I've found 
the "Compare" capabilities in Eclipse pretty fantastic for white space 
problems, because you can toggle between ignoring and respecting white 
space changes.


Eric.

Re: SVN and Active Directory

[Eric Johnson]

Absolutely, but by way of using Apache mod_auth_ldap, and AD's LDAP API.

Eric

On 4/19/16 12:53 PM, Gronde, Christopher (Contractor) wrote:


Has anyone in here successfully integrated SVN with Active Directory 
for user authentication?  We are currently using FreeIPA and user 
account management is the bane of my existence.  If anyone has or 
knows of any documentation for integrating Active Directory with SVN 
(preferably 1.9 since we are going to upgrade to that version) that 
would be much appreciated.


V/r

Chris Gronde (CTR)

Navstar, INC.

Linux Systems Administrator

Network Monitoring Engineer

Financial Crimes Enforcement Network (FinCEN)

Technology Solutions and Services Division (TSSD)

Tel: 703-905-3578

Cell: 571-318-7743

Office: 2041K

Re: An established connection was aborted by the software in your host machine.

[Eric Johnson]

I've seen this kind of error, and usually it seems to map to problems with
the network connectivity. In addition to checking for Apache configuration,
also check for proxies that might be disrupting the communication.

You're also using a very old version of the Subversion server, and
presumably an old version of Apache. Upgrading will almost certainly
address some of the problems you're seeing.

For upgrade alternatives, you'll need to go outside of the stock CentOS
repositories. For example:
http://opensource.wandisco.com/centos/6/svn-1.8/RPMS/x86_64/



On Fri, Apr 15, 2016 at 9:43 AM, Gronde, Christopher (Contractor) <
christopher.gro...@fincen.gov> wrote:

> We have a user who is trying to commit a 5MB file (he says the file is
> larger than he normally uploads) and he is receiving the error in subject
> of this email.  I have looked at the apache error_log (after upping the
> logging to debug) as well as access_log, and find nothing that shows why
> this error is happening.  Someone suggested changing the name of the file
> and attempting again, but that did not work either.  Any assistance in
> troubleshooting this would be much appreciated.  I have googled all I can
> and can’t find any definitive answer to this issue.
>
>
> SVN Version: 1.6.11 (r934486) OS RHEL 6.7 Client OS Windows 7 Client
> Version: TortoiseSVN 1.7.7, Build 22907 – 64bit No local firewall on
> server I believe there is a physical firewall between client machine and
> SVN server No load balancer Error is generated by the SVN client when
> committing the file.
>
>
>
>
>
> V/r
>
> Chris (CTR)
>
> Linux Systems Administrator
>
> Network Monitoring Engineer
>
>
>

Re: Clarifications using Subversion

[Eric Johnson]

While the other response gives you the clues to (mostly) enforce what 
you want, I strongly encourage you to consider how to avoid using 
tooling to solve what is probably really a management problem.


The more you customize your hooks, the more difficult it might be to 
move your Subversion installation to a new environment, a cloud 
provider, or a commercial offering, just for example.


Hooks are best applied to business rules that are not about people.

You can use them the way you're asking, but long term, you might not 
want to.


Eric.

On 4/11/16 6:32 AM, Vijay Peddamallu wrote:


Dear All,

We are working on enhancing our repository and put some controls 
hence. In this regard, seek clarifications on the following. Please 
note that we are on Subversion v 1.7 as I write.


1.Is there any way that we can restrict “svn delete” command to 
limited set of users? While we understand that there is a way to 
recover the deleted version, would still like to understand if this is 
an option in first place.


2.If I lock source code on my name, can we apply a restriction that 
only I can unlock it. Otherwise, admin?


*Thanks,*

*Vijay Pedamallu*

Tech Lead, Global Oracle HRIS

Corporate Human Resources
cid:image001.png@01CFDC05.02039490
Arthur J. Gallagher & Co.

M: +91-98858-04770

www.ajg.com    | vijay_peddama...@ajg.com 



*Confidentiality Note:* This e-mail and any files transmitted with it 
are intended only for the person or entity to which it is addressed 
and may contain confidential material and/or material protected by 
law.  Any retransmission or use of this information may be a violation 
of that law.  If you received this in error, please contact the sender 
and delete the material from any computer.


cid:image002.jpg@01CFDC05.02039490

Re: SVN compatibility question

[Eric Johnson]

That's an interesting problem you describe. I'm not familiar with
SolidWorks, but you provide enough information to take some guesses.

Subversion uses an "optimistic lock" design approach which might trigger
some of the problems you're seeing. You say you wish to "prevent" users
from editing the same file at the same time, but Subversion usually doesn't
prevent people from working on the same files at the same time. Compounding
that, it sounds like the SolidWorks project changes many files at the same
time. This means that not only can you not prevent users from making those
changes, the SolidWorks users don't even necessarily know which files on
disk will change for any particular change they make in the program. So if
you use Subversion to share changes to files, you may get an odd
combination of people over-writing other people's changes, and changes to
files that appear independent, but turn out to be contradictory. (This
happens with source code all the time, but is much easier to resolve, it
sounds like).

To sidestep the optimistic lock problem, perhaps adopt a convention where
you have a "semaphore" file. Use Subversion's pessimistic lock capability (
http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html). People
shouldn't work on a project unless they can get a pessimistic lock on the
project. This will require training your users

In addition to that, it sounds like SolidWorks is completely oblivious to
Subversion - so if it goes and renames or changes files, it doesn't perform
the Subversion actions. Particularly if SW does a lot of renaming, this
will cause problems, because then the users will have to go and do fix-up
operations with the Subversion working copy - deleting files here and there.

A quick browse of the internet suggests that using Subversion (TortoiseSVN)
is likely going to be painful, unless you figure out the corner cases, and
train your users to recognize them and fix them before they are a problem (
https://forum.solidworks.com/thread/48193).

You've indicated that upgrading is a problem. Are you talking about
upgrading the server, or the clients? You should be able to upgrade the
server without too much worry. What version of the server are you running?
That might be the place to start.

Note that with the newer Subversion clients (starting 1.7, I think),
Subversion only puts one ".svn" folder at the root of the working copy,
instead of a ".svn" folder in each directory of the working copy. I'm
guessing that SolidWorks expects a folder with few or no extraneous files
in it - perhaps it is even modifying the contents of the .svn folder. To
avoid that problem, make sure you check out a working copy that is a
*parent* of the SW project folder, so that SW doesn't ever see/touch the
.svn folder. From your description, I'm guessing this is part of the
problem you've run into after upgrading clients to a newer version of
Subversion.

There's a different way of thinking about this problem that might work
better for you, but it depends on your users.

One option is to use Subversion to "snapshot" the work that people are
doing, and commit those snapshots. For this you might find treating your
"project" as a "vendor" folder instead. See
http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general
.

Using the vendoring approach, have people check out a working copy, but not
do their work in that copy - instead do their work from a folder that is an
*export* of the Subversion working copy (no extraneous .svn folders). Then
when their work in SW is done, use svn_load_dirs to change the Subversion
working copy to look just like the SW project folder. Then commit that.
Then have the next person check out the latest version of the working copy,
export into a clean folder, and make their changes. Truly a pain, though,
so probably a last resort. This approach might be useful for learning how
SW changes files, so you can train people on what is happening, though.

My suggestions, summarized:

   - Upgrade your server (what version are you at now?) - this shouldn't
   affect clients, except possibly to make everything work better.
   - Upgrade your clients, but *make sure* your users check out working
   copies at the parent folder of the SW project, not the SW folder itself.
   This may require reorganizing the directory structure of the repository so
   that you can check out the parent folder without grabbing too much extra
   stuff.
   - Identify and train your users on the various scenarios that they will
   encounter.

Hopefully that gives you some clues.

Good luck!

Eric.

On Tue, Mar 29, 2016 at 10:53 AM, Eric Ahlstrom 
wrote:

> To whom it may concern,
>
> Sorry, I'm not a software developer so this message is not following the
> protocol for reporting bugs.  Our company primarily deals with aircraft
> electronics integration.  Software is a small part of our operations and
> our people have used Tortoise SVN 

Re: Modifying svn:log property: good or bad?

[Eric Johnson]

We definitely enforce restrictions. We also log all revprop changes.

Keep in mind that this information is key to establishing a historical
record of what happened with your source code. If you're lawyers haven't
advised you already, you might want to consider what happens if you ever
get hauled into court, and need to testify about the quality of the
historical information in your Subversion repositories. You want to keep
the list of people that can change the revprops (and the revisions
themselves) to an absolute minimum.

Eric.


On Fri, Feb 26, 2016 at 10:03 AM, Alfred von Campe <alf...@von-campe.com>
wrote:

> Eric:
>
> Thanks for the feedback.  Do you enforce just appending to the svn:log
> property or is that just the policy and everyone follows it?  Same question
> for modifying the other recprops: do you enforce it or is it just policy?
>
> Alfred
>
> On Feb 26, 2016, at 12:42, Eric Johnson <e...@tibco.com> wrote:
>
> We looked at this problem, and decided that typos were not sufficient
> reason to tamper with history.
>
> However, committers sometimes forget critical information, such as the bug
> # associated with a commit, or other information critical to a useful audit
> trail.
>
> To avoid losing history, and yet allow for such critical information, our
> work-around is to allow changes to the svn:log property, but *only* allow
> appending to existing contents. Once we put that in, people stopped
> complaining.
>
> We don't allow users to change any other revprops.
>
> Eric.
>
> On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe <alf...@von-campe.com>
> wrote:
>
>> Is modifying the unversioned svn:log property considered bad practice?
>> We’re about to upgrade to a new Subversion server at work, and the central
>> group that manages that server will no longer allow modifications to
>> unversioned properties.  Their main reason is so that third party tools
>> like Jira and Crucible, that have daemons that scan check-in comments for
>> keywords and index the results, don’t have to be re-run again to re-index
>> updated commits.  They are recommending creating a property on all the
>> files that were affected in a commit (the name/value of the property is not
>> important), and then committing that change with the “correct” check-in
>> comment.  I can see their point, but sometimes you just want to correct a
>> minor typo in a commit log.
>>
>> I’m just wondering what collective wisdom of this group is in regards to
>> updating the svn:log property (or other unversioned properties)?
>>
>> Thanks,
>> Alfred
>>
>>
>
>

Re: Modifying svn:log property: good or bad?

[Eric Johnson]

We looked at this problem, and decided that typos were not sufficient
reason to tamper with history.

However, committers sometimes forget critical information, such as the bug
# associated with a commit, or other information critical to a useful audit
trail.

To avoid losing history, and yet allow for such critical information, our
work-around is to allow changes to the svn:log property, but *only* allow
appending to existing contents. Once we put that in, people stopped
complaining.

We don't allow users to change any other revprops.

Eric.

On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe 
wrote:

> Is modifying the unversioned svn:log property considered bad practice?
> We’re about to upgrade to a new Subversion server at work, and the central
> group that manages that server will no longer allow modifications to
> unversioned properties.  Their main reason is so that third party tools
> like Jira and Crucible, that have daemons that scan check-in comments for
> keywords and index the results, don’t have to be re-run again to re-index
> updated commits.  They are recommending creating a property on all the
> files that were affected in a commit (the name/value of the property is not
> important), and then committing that change with the “correct” check-in
> comment.  I can see their point, but sometimes you just want to correct a
> minor typo in a commit log.
>
> I’m just wondering what collective wisdom of this group is in regards to
> updating the svn:log property (or other unversioned properties)?
>
> Thanks,
> Alfred
>
>

Re: Help extending subclipse

[Eric Johnson]

Wrong mailing list.

You probably want the "dev" mailing list from this page:
http://subclipse.tigris.org/ds/viewForums.do

Eric.

On Thu, Feb 11, 2016 at 8:27 AM, Brunoais  wrote:

> Hi,
>
> I want to make a plugin to the subclipse.
> Broadly speaking, it would work like this:
>
> When the commit dialog appears, below the " comment>", I want to add a file browser window that allows to choose a file
> location in the filesystem.
>
> For that file, I want to create a listing (full file path) of all the
> files that are being committed (additions, editions and deletions). That
> record is made only when the commit is issued, no need to do it before that.
>
> I also want to associate the file to where it is stored and the message
> written in the commit messages list, but that's for later.
>
> For starters, I need to know to which extension points should I attach my
> code to and which dependencies will my code need. Are you able to help me?
> Anything is welcome.
>
> Thanks in advance
>
>
>
>

Re: Creating working copy without checkouting- to use svn add and svn ci form cron for /home

[Eric Johnson]

Your questions are somewhat confusing, because you seem to state a number
of different problems that you want to solve:
- which students are copying?
- how to do a checkout without a working copy?
- can you just copy the .svn folder of a working copy some place else? (And
expect what to work, exactly?)

I think your first question is bigger than this mailing list, and I don't
see how Subversion can help you solve that problem.

Your second question doesn't make sense to me, insofar as I don't
understand what you mean by a working copy without a checkout? Do you mean
you want person A to checkout, and B uses a working copy? Or do you mean
you want a checkout at one point in time, and then later use of the same
working copy when the server is not available?

For your third question, I have a suspicion you'll be unsatisfied trying
that, as the first thing you'll need to do is an "svn revert -R ." to
restore the missing files, which will effective amount to having a clean
checkout.

Eric.


On Fri, Dec 11, 2015 at 7:35 AM, Peter Fodrek  wrote:

> Dear Subversion experts,
>
> I would like to monitor /home directory for X-host that is used by
> 20 X-terminals for eductional classroom.
> I want to monitor students work flor evalution a to find out who is
> cheating
> by copying others programs.
>
> I was done svn import for /home succesfully.
> I do not want to checkout repository to the  /home as it is risky
>
> svn commit does not work as /home is not working copy o the repository
> svn import does not work as well becuase of duplicity
>
>
> Is there any way to setup /home as working copy without checkout,please?
>
>
> I was mentioned  that I do chcekout in another directory and simply copy
> .svn
> directory into /home as a workarround. Does anybody know if it will
> work,please ? Is it correct or it is solution with as less as possible
> incorrectness, please?
>
>
> I look forward hearing from you
>
> Yours faithfully
>
> Peter Fodrek
>

Re: Unexpected HTTP status 400 'Bad request'.

[Eric Johnson]

Is it feasible to dump and load the repository in question?

You could re-load it, and see if the repository still has problems.

On the other hand, if the load fails at a specific revision, that might
give you more of a clue about what is going wrong.

Eric.

On Mon, Dec 7, 2015 at 10:13 PM, Chris Capon  wrote:

> On 2015-12-07 20:48, David Chapman wrote:
>
>>
>> Have you verified that the repository on the server is not corrupt?
>> Perhaps the disk has a bad sector on the drive, and only that repository is
>> affected.  Or maybe the hard drive itself is failing, and the other
>> repositories have simply been "lucky" so far.
>>
>> # svnadmin verify /path/to/repository/root
>>
>> I ran the svnadmin command and the admin tool verified all the revisions
> and reported no errors.  The same problem still persists. I can only get
> part way through a checkout before it fails.
>
> By the way, if I change the local svn checkout on the server to a file
> reference rather than going through apache2 and https then the checkout
> completes with no problems.  So,
>
> svn checkout https://localhost/svn/repository/dev/trunk --username
> myself  dev
>
> fails part way through after 5 to 10 files, where
>
> svn checkout file:///root/subversion/root/repository/dev/trunk
> --username myself dev
>
> checks out the entire repository without errors.
>
>
>

Re: undo svnadmin pack

[Eric Johnson]

Best I can think of is to dump the repo, create a new one to load it into,
turn off packing on the target repo, and then do the load.

Eric.

On Wed, Dec 2, 2015 at 3:54 AM, Ignacio González (Eliop) <
igtorque.el...@googlemail.com> wrote:

> Hello.
>
> Is there a simple way to undo the effects of an "svnadmin pack" command?
> If not, is there a complex way?
> If needed, I can retrieve the individual files that compose the packed
> file (there is only one), but I don't know what other files I would have to
> modify (assuming they could be edited somehow)
>
> svn 1.8.13, Linux
>
> Thanks.
>

Re: Authentication in Subversion 1.8+

[Eric Johnson]

My guess is that it is somehow related to inherited properties.

https://subversion.apache.org/docs/release-notes/1.8.html#iprops

Eric.

On Thu, Oct 29, 2015 at 7:37 PM, Mark Bidewell  wrote:

> We have a Subversion repository which by default requires authentication
> disables all anonymous access, but enables anonymous access for certain
> directories.  For Subversion 1.6 and 1.7 clients this works fine for
> anonymous access.  However, when using Subversion 1.8 and 1.9, a request
> for the same directory that worked fine under 1.7 requires authentication.
> A quick wireshark seems to indicate that during the PROPFIND calls made by
> 1.8+ clients, the client somehow hits an authenticated path.
>
> Can anyone shed some light on this behavior?
>
> Thanks
>
> --
> Mark Bidewell
> http://www.linkedin.com/in/markbidewell
>

Re: how to integrate a zip based archive into svn

[Eric Johnson]

Check out the svn_load_dirs script. Look for the instructions in the
manual under managing the "vendor" branches.

There will still be a bunch of work to resolve moves & renames, but
should be much easier.

Eric


> On Oct 18, 2015, at 1:13 AM, Eckard Klotz  wrote:
>
> Hello All.
>
> My question is associated with setting up a new SVN archive for an old 
> project without loosing the old file-versions.
>
> Even I'm programming  for nearly 20 years and have a open source project for 
> nearly 10 years I'm new in SVN. Until now I have archived my project by 
> zipping my source folder.
> Now I wonder if there is a way supported by SVN to transfer every zip file as 
> one revision into a new fresh SVN archive. It is clear to me that this will 
> not contain the automatic creation of comments. But having a archive that 
> contains the historical files and that allows me to step back to earlier 
> revisions would be helpful.
>
> Best regards,
>Eckard Klotz

Re: Access to non SVN files via svn property - Feature request

[Eric Johnson]

Sounds like you're trying to solve the problem with the wrong tool.

What you probably want is a build system that fetches binary/built
dependencies for you. Since you're using Nexus, why not use Maven to fetch
said large binaries? You may need to spend time wrapping some of your
binaries up with Maven POM metadata, but you can get that done a lot faster
than any possible chance of success waiting for a new feature in a
Subversion client?

If you don't want Maven as your build tool, perhaps you can use Apache Ivy
to fetch your dependencies instead?

Eric.



On Fri, Oct 16, 2015 at 12:58 AM,  wrote:

> Hi all,
>
> What feature do we suggest? A new svn property (aliens? :-) to reach
> "pure" http paths; during svn checkouts, when this property is followed,
> the standard http protocol is used and the resulting subtree is marked as
> "specially managed", so that svn status does not see it as a standard
> unversioned tree (this is to avoid that the user, by mistake, adds the tree
> to SVN repo. Similar ideas apply for svn export and svn commit.
>
> Here is the background: in our company we have been managing SVN
> repositories since 2007; one of these repo has more than 80 revisions
> and uses almost 140GB.
> The reason for this large size is that, despite of the rules we stated,
> many users committed big binary files. Some were by mistake, some because
> the users found SVN the most reasonable place.
> For the latter case I am referring to libraries and artifacts that are
> necessary to build the final product, that will be stored using the company
> PLM tool, not in SVN repo.
> We then introduced an artifact repository manager, namely Sonatype Nexus,
> to store these artifacts;  we store in Nexus any kind of artifact,
> whichever is the programming language used to produce it.
> For development trees we are used to set svn:externals property to access
> source files, possibly in other SVN repositories; we know it is "legal" to
> access binary files and libraries too, provided they are stored in a
> Subversion repository. But we strongly discourage such a behaviour and
> suggest to use Nexus instead.
> What is our build process for a large project?
> The modules are debugged and tested, the resulting artifact is stored (and
> versioned) on Nexus.
> When programmers have to produce the final product they need to have a
> complete tree, made of sources for the main tree and of objects/libraries
> for the modules.
> The problem is well known: it is impossible to access Nexus repositories
> via http through svn:externals: SVN expects to use the same protocol for
> the whole tree, externals included.
>
> I did not find anything useful on the web, apart from the suggestion to
> use scripts to produce the correct environment, but such a solution depends
> on the development environment: for some developers it is very easy, for
> others it is not.
>
> Thanks in advance,
> *Francesco Policastro*
> Product Data & Configuration Management
> Selex ES, A Finmeccanica Company
> Via Puccini 2
> 16154 Genova (Italia)
> (Tel.) +39 010 6584092
> (Email) francesco.policas...@selex-es.com
> www.selex-es.com
>
> This email and any attachments are confidential to the intended recipient
> and may also be privileged. If you are not the intended recipient please
> delete it from your system and notify the sender. You should not copy it or
> use it for any purpose nor disclose or distribute its contents to any other
> person.
> Questa e-mail e tutti i suoi allegati sono da intendersi inviati in via
> riservata all'effettivo destinatario e possono essere soggetti a
> restrizioni legali. Se non siete l'effettivo destinatario o avete ricevuto
> il messaggio per errore siete pregati di cancellarlo dal vostro sistema e
> di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi
> titolo, la divulgazione o la distribuzione dei contenuti di questa e-mail a
> qualunque altro soggetto.
> [image: Tree]
> Prima di stampare questa comunicazione consideratene, per favore,
> l'impatto ambientale
> Please consider the environment before printing this email

Re: Problem in reading the Subversion directory - Please help

[Eric Johnson]

Looks like the user name isn't being recorded in the log.

I suggest re-enabling read access to everyone, then making sure that the
log records the user name for successful access. Make sure it is what you
expect, and only then block the reads for all users.

Eric

On Oct 10, 2015, at 3:31 AM, Ranjeet Singh <ranjeetsinghsal...@gmail.com>
wrote:

Hi Eric,

So, i was getting below error so can you help me on this by recognizing
what i am doing.

Error on Apache log file: [Fri Oct 09 08:53:54 2015] [error] Access denied:
- OPTIONS KH:/


Regrards
Ranjeet

On Fri, Oct 9, 2015 at 10:06 PM, Eric Johnson <e...@tibco.com> wrote:

> Please keep discussions on the mailing list.
>
> Eric.
>
> On Fri, Oct 9, 2015 at 1:14 AM, Ranjeet Singh <
> ranjeetsinghsal...@gmail.com> wrote:
>
>> Hi Eric,
>>
>> I am getting below error in the log files:
>>
>> [Fri Oct 09 08:53:54 2015] [error] Access denied: - OPTIONS KH:/
>>
>>
>> Regards
>>
>> Ranjit Singh
>>
>> On Fri, Oct 9, 2015 at 6:19 AM, Eric Johnson <e...@tibco.com> wrote:
>>
>>> I don't see any obvious oversights. Check your Apache log files to see
>>> what's in the error log.
>>>
>>> Eric.
>>>
>>> On Thu, Oct 8, 2015 at 7:41 AM, Ranjeet Singh <
>>> ranjeetsinghsal...@gmail.com> wrote:
>>>
>>>> Hi Team,
>>>>
>>>> I have installed SVN in my linux box and I am using version 1.6.11
>>>> (r934486) of SVN and I am facing some problem with the configuration.
>>>>
>>>> I have created one repository named as KH and earlier i have given the
>>>> read all access in auth file - like this
>>>>
>>>> [groups]
>>>> support_rw = ranjeet, rahul, monika, devesh
>>>>
>>>> [KH:/]
>>>>
>>>> * = r
>>>> @support_rw = rw
>>>>
>>>> and now I wanted to delete remove everyone to read this directory so i
>>>> did this
>>>>
>>>> [KH:/]
>>>>
>>>> * =
>>>>
>>>> @support_rw = rw
>>>>
>>>> And now i am not able to login into my directory.
>>>>
>>>> I have read some articles about it. I have also checked my
>>>> subversion.conf file in subversion and it is like this only:
>>>>
>>>> 
>>>>  LoadModule dav_svn_module modules/mod_dav_svn.so
>>>>
>>>> 
>>>> LoadModule dav_svn_module modules/mod_dav_svn.so
>>>> 
>>>> 
>>>> LoadModule authz_svn_module   modules/mod_authz_svn.so
>>>> 
>>>>
>>>>
>>>> 
>>>>DAV svn
>>>>SVNParentPath /var/www/svnRepos/KnowHow
>>>>
>>>># Limit write permission to list of valid users.
>>>>
>>>>   # Require SSL connection for password protection.
>>>>   # SSLRequireSSL
>>>>
>>>>   AuthType Basic
>>>>   AuthName "Authorization Realm for KH repository"
>>>>   AuthUserFile /etc/httpd/svn-conf.d/svn-auth-conf-KH
>>>>   AuthzSVNAccessFile /etc/httpd/svn-conf.d/svn-acl-conf-KH
>>>>   Require valid-user
>>>>
>>>> 
>>>>
>>>>
>>>> Now i am unable to login into my repository.
>>>>
>>>> I am getting this error:
>>>>
>>>> "server sent unexpected return value (403 Forbidden)"
>>>>
>>>> Please can you help me in this.
>>>>
>>>>
>>>> Thanks
>>>> Ranjit Singh Saluja
>>>> Ph: +91-8826157712
>>>>
>>>
>>>
>>
>

Re: Problem in reading the Subversion directory - Please help

[Eric Johnson]

I don't see any obvious oversights. Check your Apache log files to see
what's in the error log.

Eric.

On Thu, Oct 8, 2015 at 7:41 AM, Ranjeet Singh 
wrote:

> Hi Team,
>
> I have installed SVN in my linux box and I am using version 1.6.11
> (r934486) of SVN and I am facing some problem with the configuration.
>
> I have created one repository named as KH and earlier i have given the
> read all access in auth file - like this
>
> [groups]
> support_rw = ranjeet, rahul, monika, devesh
>
> [KH:/]
>
> * = r
> @support_rw = rw
>
> and now I wanted to delete remove everyone to read this directory so i did
> this
>
> [KH:/]
>
> * =
>
> @support_rw = rw
>
> And now i am not able to login into my directory.
>
> I have read some articles about it. I have also checked my subversion.conf
> file in subversion and it is like this only:
>
> 
>  LoadModule dav_svn_module modules/mod_dav_svn.so
>
> 
> LoadModule dav_svn_module modules/mod_dav_svn.so
> 
> 
> LoadModule authz_svn_module   modules/mod_authz_svn.so
> 
>
>
> 
>DAV svn
>SVNParentPath /var/www/svnRepos/KnowHow
>
># Limit write permission to list of valid users.
>
>   # Require SSL connection for password protection.
>   # SSLRequireSSL
>
>   AuthType Basic
>   AuthName "Authorization Realm for KH repository"
>   AuthUserFile /etc/httpd/svn-conf.d/svn-auth-conf-KH
>   AuthzSVNAccessFile /etc/httpd/svn-conf.d/svn-acl-conf-KH
>   Require valid-user
>
> 
>
>
> Now i am unable to login into my repository.
>
> I am getting this error:
>
> "server sent unexpected return value (403 Forbidden)"
>
> Please can you help me in this.
>
>
> Thanks
> Ranjit Singh Saluja
> Ph: +91-8826157712
>

Re: Leightweight tools for automated svn update + some scripting

[Eric Johnson]

As Joseba indicated, try Ansible. Salt Stack also has an "agentless" mode.

I use Ansible to deploy / configure Subversion and mirrors.

And of course, then you can track your configuration changes in version
control.

As this question is somewhat off topic from this mailing list, I suggest
learning more about Ansible & Salt Stack, and asking in the appropriate
forums for those.

Eric.

On Fri, Oct 2, 2015 at 8:01 AM, Thorsten Schöning 
wrote:

> Hi all,
>
> I'm doing a bit research for our somewhat small company how to best
> update home grown services, web applications and configurations on
> production and testing servers. We have only few of them, but many
> more working copies all over the place with various layouts, some
> applications even consist of independent wcs in different folders for
> historical reasons and such.
>
> There's a lot of tools available around the subject "continuous
> delivery", things like Puppet, Chef etc. are mentioned very often, but
> all of those look very heavyweight to me currently. Some come with
> their own web server, database, need "configurations" implemented in
> programming languages we have no experience with, are really bad
> debuggable locally and whatever... What I'm currently more interested
> in is something between doing things manually and such things like
> Puppet, because I don't seem to be very good at finding such software,
> if it exists.
>
> What I would need is something polling some repos, like commit
> monitors, only server based without GUI and such, and on commits
> updates some working copies. Additionally, I need to be able to at
> least restart services. I guess this covers around 95% of my use
> cases and reads like some flexible commit monitor and a scripting
> interface, but I hope that maybe some of this scripting could be
> avoided and replaced by really simple configurations. Of course this
> would only be useful if such an application doesn't bring it's own web
> server, database and Ruby runtime environment...
>
> Do you know of something like that available? Thanks!
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>

Re: Data lost in a subversion repository

[Eric Johnson]

First do an svnadmin verify, and see where that fails

If that works, see if you can do an svnadmin dump with different ranges,
and see if you can figure out the revisions where it fails.

If you can identify specific revisions that are broken, you might be able
to recreate them manually.

Eric.



On Tue, Sep 29, 2015 at 8:12 AM, thomas  wrote:

> Dear ladies and gentlemen,
>
> my name is Thomas Riller, I am working at the technical university of
> Munich.
>
> I am sorry, that I directly contact you.
>
> We have a problem (self made) with a subversion repository.
>
> The repository was stored at a personal directory and is damaged. This
> means, some revision files are missing.
>
> The repository uses the fsfs format 6 layout sharded 1000.
>
> We have a working copy of the project in the last version.
>
> Do you know any possibility, to extract datas from the /revs directory. We
> do not expect to get all datas back, but we would be happy, to get some
> diffs back from this files.
>
> Best Regards
>
> Thomas Riller
>

Re: path based authz and write-through proxy

[Eric Johnson]

In our deployment with mirrors, the access file is generated from
information stored in Subversion.

The act of mirroring the repository with the access information in it
triggers the post-commit hook which updates the permissions locally.

Eric.


On Thu, Sep 24, 2015 at 12:34 PM, Aaron Friesen  wrote:

> All,
>
> I have been tasked with setting up a mirror of several repositories with
> write-through back to the master.
>
> We have path based authorization on the master.
>
> The svn book simply states to:
>
> ... configure each of your "slave" servers in the exact same way,
> but add the special SVNMasterURI directive to the  block.
>
> That works, but seems to require synchronization of the authz information
> on all servers.
>
> What methods have people used to keep them synchronized?
>
> Here is the relavent  configuration:
>
> ==
> 
>DAV svn
>SVNParentPath "E:/csvn/data/repositories"
>SVNReposName "CollabNet Subversion Repository"
>
>   
> SetOutputFilter DEFLATE
>   
>
>   
> Require user sync
>   
>   AuthzSVNAccessFile "C:\csvn\data/conf/svn_access_file"
>   SVNPathAuthz short_circuit
>   AuthzForceUsernameCase Lower
> 
>
> # Work around authz and SVNListParentPath issue
> RedirectMatch ^(/svn)$ $1/
> 
>DAV svn
>SVNParentPath "E:/csvn/data/repositories"
>SVNReposName "CollabNet Subversion Repository"
>
>   
> SetOutputFilter DEFLATE
>   
>   AuthzSVNAccessFile "C:\csvn\data/conf/svn_access_file"
>   SVNPathAuthz short_circuit
>   SVNListParentPath On
>   AuthzForceUsernameCase Lower
>   SVNMasterURI http://192.168.15.18:8080/svn
> 
> ==
>
> By restricting access on  to just the user "sync", and
> the SVNMasterURI in , is there any major reason not to
> simply remove all path based restrictions on the mirror and let the master
> perform that function so that the authz on the mirror doesn't have to
> change?
>
> Thanks,
>
> Aaron
>

Re: Incomplete SVN dump files

[Eric Johnson]

Hi Bert,

On Wed, Sep 16, 2015 at 2:33 AM, Bert Huijben <b...@qqmail.nl> wrote:

>
>
> > -Original Message-
> > From: Andreas Mohr [mailto:a...@lisas.de]
> > Sent: woensdag 16 september 2015 07:48
> > To: Eric Johnson <e...@tibco.com>
> > Cc: b...@qqmail.nl; users@subversion.apache.org
> > Subject: Re: Incomplete SVN dump files
> >
> > Hi,
> >
> > On Tue, Sep 15, 2015 at 05:26:38PM -0700, Eric Johnson wrote:
> > >I just checked, and there aren't any open bugs about this.
> > >Interrupting svnrdump can result in a dump file with not all the
> files of
> > >the last commit in the dump record. Accidentally use that dump file
> to
> > >load into a new repository, and the resulting repository will not be
> a
> > >copy of the original.
> > >My particular use case, I was trying to suck down a large
> repository.
> > >Connection interrupted part way through. I resumed from part way
> through
> > >(using the --incremental option) into an additional dump file. Then
> did a
> > >load of those two dump files. Did not yield a copy of the original
> > >repository, though.
> > >This seems like a critical issue for possible data loss when copying
> > >repositories from machine to machine using svnrdump.
> >
> > AFAICS (not an svnrdump expert here) very well described and to the
> point.
> > You just managed to pinpoint a rather important serialization format
> > that seemingly isn't fully properly atomically transaction-safe...
> > (good catch!)
>
> In some ways a dumpfile is a stream and not a file... and when you use the
> commandline tools you always obtain it from stdout.
>
> I could argue that you in that case should check if the operation exited
> successfully or with an error.
>

In my specific case, I'm trying to suck GB of data from Europe to the
Western US. And apparently I cannot depend on the connect being stable long
enough to last for the whole download.

So if the dump of the last commit is incomplete, I an error code tells me,
what, exactly? That I need to manually edit the stream that I just dumped
into a file? That I should discard the whole dump, and start again?


>
> After an error you can't trust that the final portion is ok.
>

Sure, but why not encode that in the dump itself! The absence of an
"end-commit" trailer could be a signal to every tool that uses the dump
that the commit is not complete, and the transaction could be discarded!


>
>
> The stream was also deliberately designed in a way that you can
> incrementally generate it... E.g. after each new revision or as a daily
> backup operation.
>



>
> Adding some 'this is the end' marker would break those use cases, that we
> have been using since the day subversion was self-hosted. (Long before 1.0)
>
> Sounds like an argument for a "start commit / end commit" frame in the
dump. So if you want to support this use case, adding an "end-of-stream" at
the end of the stream wouldn't be sufficient. Right now, the dump file
apparently just has a "start commit" indicator. So it breaks everything.


>
> And when loading from a stream we can't continue reading to the end to see
> if there is a final marker, as at that point we aren't able to go back to
> the start and start the whole process.
> (I've used '$ svn dump  | ssh  svnadmin load ...' more than a few
> times for repository migrations)
>

SVN claims to be transactional with commits. Surely, svnadmin load can
discard the last commit from a load if it was incomplete. Actually, doing
anything else is just asking for occasional data corruption.

I'm filing an issue.

Eric

Re: Incomplete SVN dump files

[Eric Johnson]

Hi Brane,

>> On Sep 16, 2015, at 11:28 AM, Branko Čibej <br...@apache.org> wrote:
>>
>> On 16.09.2015 20:03, Eric Johnson wrote:
>> Hi Bert,
>>
>>>> On Wed, Sep 16, 2015 at 2:33 AM, Bert Huijben <b...@qqmail.nl> wrote:
>>>
>>>
>>>> -Original Message-
>>>> From: Andreas Mohr [mailto:a...@lisas.de]
>>>> Sent: woensdag 16 september 2015 07:48
>>>> To: Eric Johnson <e...@tibco.com>
>>>> Cc: b...@qqmail.nl; users@subversion.apache.org
>>>> Subject: Re: Incomplete SVN dump files
>>>>
>>>> Hi,
>>>>
>>>>> On Tue, Sep 15, 2015 at 05:26:38PM -0700, Eric Johnson wrote:
>>>>>   I just checked, and there aren't any open bugs about this.
>>>>>   Interrupting svnrdump can result in a dump file with not all the
>>> files of
>>>>>   the last commit in the dump record. Accidentally use that dump file
>>> to
>>>>>   load into a new repository, and the resulting repository will not be
>>> a
>>>>>   copy of the original.
>>>>>   My particular use case, I was trying to suck down a large
>>> repository.
>>>>>   Connection interrupted part way through. I resumed from part way
>>> through
>>>>>   (using the --incremental option) into an additional dump file. Then
>>> did a
>>>>>   load of those two dump files. Did not yield a copy of the original
>>>>>   repository, though.
>>>>>   This seems like a critical issue for possible data loss when copying
>>>>>   repositories from machine to machine using svnrdump.
>>>> AFAICS (not an svnrdump expert here) very well described and to the
>>> point.
>>>> You just managed to pinpoint a rather important serialization format
>>>> that seemingly isn't fully properly atomically transaction-safe...
>>>> (good catch!)
>>> In some ways a dumpfile is a stream and not a file... and when you use the
>>> commandline tools you always obtain it from stdout.
>>>
>>> I could argue that you in that case should check if the operation exited
>>> successfully or with an error.
>> In my specific case, I'm trying to suck GB of data from Europe to the
>> Western US. And apparently I cannot depend on the connect being stable long
>> enough to last for the whole download.
>>
>> So if the dump of the last commit is incomplete, I an error code tells me,
>> what, exactly? That I need to manually edit the stream that I just dumped
>> into a file? That I should discard the whole dump, and start again?
>
> If you don't have a stable connection, then you can mitigate that by
> performing incremental dumps of one revision at a time and just retry
> any that fail. You can even do that in parallel to amortize the cost of
> opening the socket.

Yes, I can do that. Probably going to do that in chunks, otherwise it
has the same awful performance profile as svnsync over a low latency
connection.

>
> [...]
>
>> SVN claims to be transactional with commits. Surely, svnadmin load can
>> discard the last commit from a load if it was incomplete. Actually, doing
>> anything else is just asking for occasional data corruption.
>
> Commits, yes. Dump files, not so much.

A dump file itself isn't an issue. That I cannot safely pipe output
from svnrdump into svnadmin load is a *huge* problem.

>
>
>> I'm filing an issue.
>
> Good luck with that. Bert explained the reasons why dump files are the
> way they are. An "end of commit" marker does not really add much value
> compared to the other options you have, and has the really nasty side
> effect that it breaks backwards compatibility of dump files.

The end-commit marker in the dump stream is, of course just an
implementation choice. The bug is not being able to pipe the output of
svnrdump into svnadmin load.

As for backwards compatibility, the dump stream has already changed
with the deltas option to svnadmin, so an equivalent approach for
backwards compatibility could work for this issue as well.

Eric

Re: Incomplete SVN dump files

[Eric Johnson]

Hi Daniel,

The exact logistics of handling an error are probably pretty
straightforward. The underlying problem is that it is never a good
idea to pipe the output of svnrdump directly into svnadmin load,
because svnadmin cannot handle the failure unless the stream itself
carries more information.

Eric

> On Sep 16, 2015, at 3:52 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote:
>
> Eric Johnson wrote on Wed, Sep 16, 2015 at 11:03:08 -0700:
>> So if the dump of the last commit is incomplete, I an error code tells me,
>> what, exactly? That I need to manually edit the stream that I just dumped
>> into a file? That I should discard the whole dump, and start again?
>
> If you run dump and you get a non-zero exit code, then the output should
> be regarded as potentially corrupted.  In the specific case of
> ECONNABORTED, you can probably trust that the receiver received a prefix
> of what the sender sent (TCP promises that), and therefore, trust
> everything _except_ the last revision loaded.
>
> You can detect ECONNABORTED by looking at the E123456 error code.  System
> error codes are mapped into that range.  On unix the mapping is usually
> the identity (e.g., errno�2 becomes E02).  On windows there's an
> offset of 72 (see APR_FROM_OS_ERROR).  The Subversion-specific error
> codes always have the same numeric values regardless of platform (that's
> the APR_OS_START_USERERR range, E12 through E62).

Re: Incomplete SVN dump files

[Eric Johnson]

I just checked, and there aren't any open bugs about this.

Interrupting svnrdump can result in a dump file with not all the files of
the last commit in the dump record. Accidentally use that dump file to load
into a new repository, and the resulting repository will not be a copy of
the original.

My particular use case, I was trying to suck down a large repository.
Connection interrupted part way through. I resumed from part way through
(using the --incremental option) into an additional dump file. Then did a
load of those two dump files. Did not yield a copy of the original
repository, though.

This seems like a critical issue for possible data loss when copying
repositories from machine to machine using svnrdump.

I suspect the right solution to this is to put an "end of file" marker at
the end of a dump stream. If it isn't there, then svnadmin load will see
its absence, and must discard the last commit.

Eric.


On Tue, Sep 15, 2015 at 6:09 AM, Eric Johnson <e...@tibco.com> wrote:

> Hi Bert,
>
> The files that made it into the dump file were complete. It is just that
> the last commit in the dump file didn't have all of the files it was
> supposed to have.
>
> This may be a deliberate design of the dump file format, but it does mean
> that svnrdump is badly broken. Svnrdump should not be dumping a partial
> commit upon network failure!
>
> Eric
>
> On Sep 15, 2015, at 1:52 AM, "b...@qqmail.nl" <b...@qqmail.nl> wrote:
>
> In what way was the dump file incomplete?
>
>
>
> Was it broken halfway through a file? (That should have been caught via
> the checksums in the file). If a whole node edit is missing it is still a
> complete dumpfile and there is no way the current dump doesn’t know when a
> revision is done. (This allows editing the revisions in this format; as is
> sometimes done on migrations)
>
>
>
>
>
> Bert
>
>
>
>
> *From: *Eric Johnson
> *Sent: *dinsdag 15 september 2015 07:16
> *To: *users@subversion.apache.org
> *Subject: *Incomplete SVN dump files
>
>
>
>
>
> I'm in a situation where I'm dumping Subversion repositories from remote
> locations (using svnrdump).
>
>
>
> The repositories are big enough, and the network connections between
> destinations just unstable enough that the repositories aren't making it
> all in one dump call. I've noticed, for one repository in particular, that
> I actually got a dump file that had only a part of the last commit before
> the connection broke.
>
>
>
> When I loaded up the repository, Subversion reported no problems on the
> svnadmin load, but it seems to me it should have noticed that the final
> commit recorded in the dump file was incomplete, and discarded it. Instead,
> it happily loaded it, and reported no problems.
>
>
>
> At least I was lucky enough to check that it was complete, and I used a
> technique <http://superuser.com/a/315138> to drop all but the last
> revision. Now I can load a new dump file from the commit that was
> incomplete.
>
>
>
> This brings me back to my question - shouldn't the load process ignore the
> last commit if it is incomplete in the dump file? That way I know I have an
> error to address!
>
>
>
> Eric.
>
>
>
>
>
>

Re: Incomplete SVN dump files

[Eric Johnson]

Hi Bert,

The files that made it into the dump file were complete. It is just that
the last commit in the dump file didn't have all of the files it was
supposed to have.

This may be a deliberate design of the dump file format, but it does mean
that svnrdump is badly broken. Svnrdump should not be dumping a partial
commit upon network failure!

Eric

On Sep 15, 2015, at 1:52 AM, "b...@qqmail.nl" <b...@qqmail.nl> wrote:

In what way was the dump file incomplete?



Was it broken halfway through a file? (That should have been caught via the
checksums in the file). If a whole node edit is missing it is still a
complete dumpfile and there is no way the current dump doesn’t know when a
revision is done. (This allows editing the revisions in this format; as is
sometimes done on migrations)





Bert




*From: *Eric Johnson
*Sent: *dinsdag 15 september 2015 07:16
*To: *users@subversion.apache.org
*Subject: *Incomplete SVN dump files





I'm in a situation where I'm dumping Subversion repositories from remote
locations (using svnrdump).



The repositories are big enough, and the network connections between
destinations just unstable enough that the repositories aren't making it
all in one dump call. I've noticed, for one repository in particular, that
I actually got a dump file that had only a part of the last commit before
the connection broke.



When I loaded up the repository, Subversion reported no problems on the
svnadmin load, but it seems to me it should have noticed that the final
commit recorded in the dump file was incomplete, and discarded it. Instead,
it happily loaded it, and reported no problems.



At least I was lucky enough to check that it was complete, and I used a
technique <http://superuser.com/a/315138> to drop all but the last
revision. Now I can load a new dump file from the commit that was
incomplete.



This brings me back to my question - shouldn't the load process ignore the
last commit if it is incomplete in the dump file? That way I know I have an
error to address!



Eric.

Incomplete SVN dump files

[Eric Johnson]

I'm in a situation where I'm dumping Subversion repositories from remote
locations (using svnrdump).

The repositories are big enough, and the network connections between
destinations just unstable enough that the repositories aren't making it
all in one dump call. I've noticed, for one repository in particular, that
I actually got a dump file that had only a part of the last commit before
the connection broke.

When I loaded up the repository, Subversion reported no problems on the
svnadmin load, but it seems to me it should have noticed that the final
commit recorded in the dump file was incomplete, and discarded it. Instead,
it happily loaded it, and reported no problems.

At least I was lucky enough to check that it was complete, and I used a
technique  to drop all but the last
revision. Now I can load a new dump file from the commit that was
incomplete.

This brings me back to my question - shouldn't the load process ignore the
last commit if it is incomplete in the dump file? That way I know I have an
error to address!

Eric.

Re: svnsync: Authorization failed

[Eric Johnson]

Two quick thoughts (I'm not a developer, just a user of Subversion):

1) 1.6.6 is old. If you can upgrade, you might get easier to understand
error messages.

2) The sync operation is trying to sync *from* some other place. Given that
your credentials to access the zch124... repository may be fine, the likely
culprit is the credentials to access the source of the sync request data.
In any case, "svnsync help sync" will give you the command line options you
can pass to set the creds.

Eric.


On Sun, Sep 13, 2015 at 8:02 PM, Li, Hubert  wrote:

> Hi,
>
>
>
> I got the following error when I ran svnsync:
>
> [root@zch124svn01 conf]# svnsync sync svn://
> zch124svn01.ap.mot-mobility.com/miracle3
>
> …
>
> subversion/svnserve/serve.c:167: (apr_err=170001)
>
> svnsync: Authorization failed
>
>
>
> but I can co or export it with the same user, e.g.
>
> [/dept/stb/...67/svn/test]$ svn export svn://
> zch124svn01.ap.mot-mobility.com/miracle3
>
> Amiracle3
>
> …
>
>
>
> Below is my system info:
>
> [root@zch124svn01 conf]# cat /etc/issue
>
> CentOS release 6.4 (Final)
>
> Kernel \r on an \m
>
>
>
> [root@zch124svn01 conf]# svnsync --version
>
> svnsync, version 1.6.6 (r40053)
>
>compiled Oct 24 2013, 13:59:58
>
> …
>
>
>
> BTW, we can sync it before rebooting the system, but after reboot it, we
> got this error. I start the service with this command:
>
> svnserve -d -r /svn_files/svn/
>
>
>
> Thanks,
>
> Hubert Li
>
> ARRIS
>
>
>

Re: Problem with checkout when using timestamp

[Eric Johnson]

Hi Sascha,

I suspect the answer is much worse than you suspect.

Any "time-based" Subversion operation is almost certainly going to yield
the wrong answer if you ever merge two repositories with a dump/load
process. That's because the log operation doesn't scan all entries to find
the ones with the given date. I believe it just assumes that the commits
are chronologically ordered, and does a binary search to find the right
start & end point.

Thinking about this problem a little bit, I suspect the only long-term
stable solution in Subversion is probably to stop using monotonically
increasing revision numbers to reference changes. Instead, they need to be
referenced by hash or some equivalent (and then indexed). For example, if
you have a project that you dump and load into a new repository, you can
either add all those changes at the end of an existing repository - thus
messing up any date operations - or you could try to be clever, and
integrate them all by time sequence, so that the chronology is now
preserved, except that messes up all the revision numbers, so any existing
Subversion URLs that reference a revision number would now be invalid. That
doesn't mean that revision numbers go away (thus breaking every client out
there!), just that they would be an internal - and officially unstable way
of referencing changes.

There's a half-way solution that solves the issue for the date problem.
Subversion could maintain an index of entries by time, so that it can
quickly and correctly answer time-based questions, even when repositories
have been merged. That mostly solves the problem - time-based operations
work, and revision #s for the repository being imported into are still
stable. However, revisions #s from the repository being added will not be
the same as they were in their original repository. For that, I think you
have to go to the hash solution.

Eric.




On Thu, Sep 10, 2015 at 12:21 AM, <sascha.ret...@t-systems.com> wrote:

> Hello,
>
>
>
> the fix suggested by Eric will work of course. But it is not very
> practicable in case you are running a central service that supports dozens
> to hundreds of projects/repositories.
>
>
>
> In my point of view if subversion has the feature to support timestamps
> than either it should be prevented that log-entries with no timestamp /
> empty revisions are created or querying the log with entries without
> timestamp / empty revisions should not cause an error but somehow be
> ignored.
>
>
>
> At the moment we are discussing if it is practical to import export repos 
> with “--drop-all-empty-revs” and or filter all dumps before import.
>
>
>
> Best regards,
>
> Sascha
>
> ***I am not subscribed so please be so kind to add me to CC regarding this
> topic.***
>
>
>
>
>
> *Von:* Eric Johnson [mailto:e...@tibco.com]
> *Gesendet:* Dienstag, 8. September 2015 18:05
>
> *An:* Retter, Sascha
> *Cc:* users@subversion.a
> pache.org
>
> *Betreff:* Re: Problem with checkout when using timestamp
>
>
>
> Hi Sascha,
>
>
>
> I believe something about about a better error report was in the works for
> an update. Apparently, part of what's happening is getting lost between the
> server, Apache modules, Apache, and the client.
>
>
>
> You can almost certainly fix the problem by setting the svn:date revprop
> on the revisions missing the date properties.
>
>
>
> Eric.
>
>
>
>
>
> On Tue, Sep 8, 2015 at 3:32 AM, <sascha.ret...@t-systems.com> wrote:
>
> Hi Eric,
>
>
>
> Thanks you! You are right I‘ve identified several entries in the revision
> log that look like:
>
>
>
> 
>revision="24290">
>
> 
>
>
>
> And some logentries most probably have a wrong timestamp. The commit was
> made in September but logentries show a data in January. Do you have any
> idea what could be the reason for both and how we can prevent this in
> future?
>
>
>
> In my point of view subversion server should at least, if such wrong
> log-entries could not be avoided, send a more meaningful error response
> than 500 Internal Server Error.
>
>
>
> Sascha
>
>
>
> *I am not subscribed so please be so kind to add me to CC regarding this
> topic.*
>
>
>
>
>
> *Von:* Eric Johnson [mailto:e...@tibco.com]
> *Gesendet:* Montag, 7. September 2015 16:27
> *An:* Retter, Sascha
> *Cc:* users@subversion.apache.org
> *Betreff:* Re: Problem with checkout when using timestamp
>
>
>
> I have run into what might be the same issue. Can you perform svn log
> operations using timestamps? Or does that also trigger an internal server
> error?
>
>
>
> My guess is that you have some revisions in your repository that are
> em

Re: Problem with checkout when using timestamp

[Eric Johnson]

Hi Sascha,

I believe something about about a better error report was in the works for
an update. Apparently, part of what's happening is getting lost between the
server, Apache modules, Apache, and the client.

You can almost certainly fix the problem by setting the svn:date revprop on
the revisions missing the date properties.

Eric.


On Tue, Sep 8, 2015 at 3:32 AM, <sascha.ret...@t-systems.com> wrote:

> Hi Eric,
>
>
>
> Thanks you! You are right I‘ve identified several entries in the revision
> log that look like:
>
>
>
> 
>revision="24290">
>
> 
>
>
>
> And some logentries most probably have a wrong timestamp. The commit was
> made in September but logentries show a data in January. Do you have any
> idea what could be the reason for both and how we can prevent this in
> future?
>
>
>
> In my point of view subversion server should at least, if such wrong
> log-entries could not be avoided, send a more meaningful error response
> than 500 Internal Server Error.
>
>
>
> Sascha
>
>
>
> *I am not subscribed so please be so kind to add me to CC regarding this
> topic.*
>
>
>
>
>
> *Von:* Eric Johnson [mailto:e...@tibco.com]
> *Gesendet:* Montag, 7. September 2015 16:27
> *An:* Retter, Sascha
> *Cc:* users@subversion.apache.org
> *Betreff:* Re: Problem with checkout when using timestamp
>
>
>
> I have run into what might be the same issue. Can you perform svn log
> operations using timestamps? Or does that also trigger an internal server
> error?
>
>
>
> My guess is that you have some revisions in your repository that are
> empty, probably because you did a filter on a dump, but preserved
> revisions. This leaves "empty" revisions around, which then trigger a
> problem.
>
>
>
> I worked around the problem by adding svn:date revprops for the affected
> repository.
>
>
>
> Eric
>
>
>
>
> On Sep 7, 2015, at 3:08 AM, "sascha.ret...@t-systems.com" <
> sascha.ret...@t-systems.com> wrote:
>
> Hello,
>
>
>
> I am not subscribed so please be so kind to add me to CC regarding this
> topic.
>
>
>
> We are experiencing a problem with Subversion since some days and we are
> not able to recognize any changes made to the server. As soon as we try to
> checkout using a timestamp (e.g. svn --username some_user co
> https://some_u...@some.host/svn/XYZ/sources/.../trunk -r {"2015-09-02
> 09:00:00"}) we are getting:
>
>
>
> svn: E175002: Unerwarteter HTTP-Status 500 »Internal Server Error« auf
> »/svn/XYZ/!svn/me«
>
>
>
> svn: E175002: Zusätzliche Fehler:
>
> svn: E175002: REPORT-Anfrage auf »/svn/XYZ/!svn/me« schlug fehl: 500
> Internal Server Error
>
>
>
> If we checkout using HEAD or any revision-number everything works as
> expected. Problem is that jenkins’ subversion plugin uses timestamps to
> checkout for CI builds.
>
>
>
> Is this a known problem? Do you know any workaround or fix? Should I fill
> a bug-report for this problem?
>
>
>
> Best regards,
>
>
>
> Sascha Retter
>
>
>
>
>
>

Re: Problem with checkout when using timestamp

[Eric Johnson]

I have run into what might be the same issue. Can you perform svn log
operations using timestamps? Or does that also trigger an internal server
error?

My guess is that you have some revisions in your repository that are empty,
probably because you did a filter on a dump, but preserved revisions. This
leaves "empty" revisions around, which then trigger a problem.

I worked around the problem by adding svn:date revprops for the affected
repository.

Eric


On Sep 7, 2015, at 3:08 AM, "sascha.ret...@t-systems.com" <
sascha.ret...@t-systems.com> wrote:

Hello,

I am not subscribed so please be so kind to add me to CC regarding this
topic.

We are experiencing a problem with Subversion since some days and we are
not able to recognize any changes made to the server. As soon as we try to
checkout using a timestamp (e.g. svn --username some_user co
https://some_u...@some.host/svn/XYZ/sources/.../trunk -r {"2015-09-02
09:00:00"}) we are getting:

svn: E175002: Unerwarteter HTTP-Status 500 »Internal Server Error« auf
»/svn/XYZ/!svn/me«

svn: E175002: Zusätzliche Fehler:
svn: E175002: REPORT-Anfrage auf »/svn/XYZ/!svn/me« schlug fehl: 500
Internal Server Error

If we checkout using HEAD or any revision-number everything works as
expected. Problem is that jenkins’ subversion plugin uses timestamps to
checkout for CI builds.

Is this a known problem? Do you know any workaround or fix? Should I fill a
bug-report for this problem?

Best regards,

Sascha Retter

Re: Access configuration for leaves in one working copy

[Eric Johnson]

Hi Holger,

It is possible to reference two working copies in a single Subversion
command line operation. For example, you can copy or move from one
working copy to another.

Eric

> On Sep 7, 2015, at 7:34 AM, Holger Schmidt <holger.schm...@zmdi.com> wrote:
>
> It should be one working copy to be able to move resources from one leaf to 
> another or to commit changes that affect multiple leaves in one changeset.  
> The leaves belong to one project, so it was a logical choice to have them in 
> one working copy.
>
> Regards,
> Holger
>
>
>> On 07.09.2015 16:20, Eric Johnson wrote:
>> Why do you need one working copy?
>>
>>> On Sep 7, 2015, at 5:31 AM, Holger Schmidt <holger.schm...@zmdi.com> wrote:
>>>
>>> Hi,
>>>
>>> There is a repository with this directory tree:
>>>
>>> root
>>> +- dir_a
>>> +- dir_b
>>> |  +- dir_c
>>> |  +- dir_d
>>> +- dir_e
>>>   +- dir_f
>>>   +- dir_g
>>>
>>> Because there is sensible data in there user usr_u has read/write
>>> access only to dir_c and dir_g.
>>>
>>> Question: How do I configure this with the path based authorization
>>> (Apache + mod_authz_svn + AuthzSVNAccessFile) and with one working
>>> copy?
>

Re: Access configuration for leaves in one working copy

[Eric Johnson]

Why do you need one working copy?

> On Sep 7, 2015, at 5:31 AM, Holger Schmidt  wrote:
>
> Hi,
>
> There is a repository with this directory tree:
>
> root
> +- dir_a
> +- dir_b
> |  +- dir_c
> |  +- dir_d
> +- dir_e
>   +- dir_f
>   +- dir_g
>
> Because there is sensible data in there user usr_u has read/write access only 
> to dir_c and dir_g.
>
> Question: How do I configure this with the path based authorization (Apache + 
> mod_authz_svn + AuthzSVNAccessFile) and with one working copy?
>
> For one working copy usr_u needs to checkout the root directory.  That means 
> he needs read access for the root, dir_b, and dir_e.  Without read access SVN 
> denies to checkout something (initial checkout or update within sparse 
> working copy).  So I have to remove access for dir_a, dir_d, dir_f.  That 
> makes six directory sections:
>
> [/]
> usr_u = r
> [/dir_a]
> usr_u =
> [/dir_b/dir_c]
> usr_u = rw
> [/dir_b/dir_d]
> usr_u =
> [/dir_e/dir_f]
> usr_u =
> [/dir_e/dir_g]
> usr_u = rw
>
> I constantly need to monitor the repository to remove the read right for 
> newly created directories.
>
> Is there a way to configure it like this:
>
> [/]
> usr_u =
> [/dir_b/dir_c]
> usr_u = rw
> [/dir_e/dir_g]
> usr_u = rw
>
> Please Cc me in any responses as I'm not subscribed to this list.
>
> Thanks,
> Holger
>

Re: SVNListParentPath without path based authz checks?

[Eric Johnson]

Hi Thorsten,

On Thu, Aug 13, 2015 at 12:10 AM, Thorsten Schöning tschoen...@am-soft.de
wrote:

 Guten Tag Eric Johnson,
 am Montag, 10. August 2015 um 22:55 schrieben Sie:

  We let Subversion limit the listed repositories, and we have a
  separate generated list of repositories.

 How do you generate it, did you build some little tool on your own or
 are you using some kind of web app like WebSVN? I like and use the
 latter to provide web downloads, but sadly it's not maintained
 anymore.


At my company, we generate the access file from other sources. So at the
same time we're generating that, we also generate a list of repositories as
a static HTML page.

Without knowing the specifics of your setup, if you're editing the file
directly, just scan the access file when changed, and generate HTML

Eric.

Re: SVNListParentPath without path based authz checks?

[Eric Johnson]

Curious. You've come to the opposite conclusion from what we've deployed at
my company.

We let Subversion limit the listed repositories, and we have a separate
generated list of repositories.

That way, you're not playing with Subversion's access file to try to get it
right. Leave that alone, and show the list elsewhere. Seems safer, from a
security perspective - in that you cannot accidentally expose what you
don't want to.

Eric.


On Mon, Aug 10, 2015 at 11:22 AM, Thorsten Schöning tschoen...@am-soft.de
wrote:

 Hi all,

 I'm currently trying to implement access to my svn repos using
 mod_dav_svn and all my repos have a authz file to define who can
 access which paths. I would like to be able to have a listing of all
 available repos without the need for any authorization, but instead
 only if any path within the repo gets accessed authorization should be
 required.

 My configuration is as follows:

 Location /bin
 DAV svn
 SVNParentPath   /home/ams_svn_repos/Bin
 SVNListParentPath   On
 AuthzSVNReposRelativeAccessFile authz
 /Location

 The problem now is that my repos are only visible in the dir listing
 if I change my authz file to give everyone read access in /, which
 is of course not what I want. If I don't the repo's name is not
 mentioned in the listing and from reading through the logs I can see
 that the authz file gets processed and specifies denied access.

 If I remove the processing of the authz file the listing works of
 course, but I need path based access checking for the contents of the
 repo.

 Is this behavior by design or am I doing something wrong? From my
 point of view SVNListParentPath is managed outside of the repo and
 therefore authz should be ignored on that level.

 Thanks for your input!

 Mit freundlichen Grüßen,

 Thorsten Schöning

 --
 Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
 AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

 Telefon...05151-  9468- 55
 Fax...05151-  9468- 88
 Mobil..0178-8 9468- 04

 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
 AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: Feature request: Save the old file when svn revert

[Eric Johnson]

Seems to me that stashing the before-reverted copies could go into some
recycle bin / trash folder underneath the .svn folder at the root of
the working copy. And by default, the client could clean out files
time-stamped over a month old, so it doesn't perpetually grow. Cleanup
could happen on commit operations.

Then a new options could be added to the svn revert command. I'm thinking:
 - revert --undo path/to-local/file # undoes the revert
 - revert --list-undoable # lists all the available files with a revert
that can be undone

This has the advantages of not changing the existing semantics of the
revert operation, doesn't clutter up the directories of the working copy,
and self-cleans.

Eric.

On Tue, Jul 21, 2015 at 9:14 AM, Andreas Mohr a...@lisas.de wrote:

 On Tue, Jul 21, 2015 at 11:06:06AM +0200, OBones wrote:
  Grierson, David wrote:
  I completely understand that the action of sending to the Recycle Bin
 (in TortoiseSVN) is very system specific.
  
  To simply rename the item being reverted as $item.$backupSuffix before
 then restoring the pristine item is presumably not that system specific?
  
  Having this functionality in the base tool would then provide a benefit
 to all users and not just those using a specific IDE.
  I would very much prefer if this could be an option that is not enabled
 by
  default. I mean, this would clutter the filesystem with many files that
 one
  would have to delete manually, especially when considering that some of
 us
  are using less than optimal filesystems when it comes down to lots of
 small
  files.

 This seems to hint that the revert-backup item
 possibly should *not* be placed in the same directory as the item,
 but rather in an alternate tree base
 (creating random similarly-named files next to each other in unexpected
 ways
 seems just asking for trouble,
 and lots of it - think build system mechanisms, other automatic
 handling, ...).


 Knee-jerk sample (hard-coded, non-elegant, read: day-to-day occurrence ;):

 unit_test1.c
 unit_test2.c
 unit_test1.c.revert_backup

 cp -a unit_test* some_dir/
 some_dir/tool unit_test*


 One might even implement this as a config option (revert tree base
 directory),
 and if left unspecified/empty
 svn could fall back to having .reverted files local,
 or another mode might be to record this within the local .svn dirs.

 Andreas Mohr

 --
 GNU/Linux. It's not the software that's free, it's you.

Re: Sync-ing two SVN repositories

[Eric Johnson]

Sounds like you want to use an approach called vendoring.

http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html

Effectively, you get dumps from the vendor, and vice-versa(?). You
shouldn't care / need to care what their source looks like, or even where
it comes from. You just want to make your copy of the latest source in your
repository look like what the vendor has.

If the vendor (or you) decides to switch to some other version control
system (such as Git), it should be irrelevant to the other party.

On the other hand, what you're describing is a typical scenario for
distributed version control. So you might want to look into Git or
Mercurial. Mercurial is slightly more natural for Subversion users.

Eric.

On Mon, Jul 20, 2015 at 8:08 AM, Mani Raju mani...@gmail.com wrote:

 Hi,
 My company  vendor planning to maintain 2 independent SVN
 repositories(URLs  server names are different)  need to merge between 2
 repositories.

 Is SVN 1.8 support merging between 2 repos at trunk or branch level?
 Is any tool provides auto sync or auto merging without manual intervention

 Tried with TortoiseSVN  by creating 2 repositories, merged  getting the
 below error.Refer attached.

 ERROR -- svn: 'x' isn't in the same repository as 'y' 

 I got the below link to sync between branches from different
 repositories.Provided solution in this link is to maintain
 the same UUID for both repo.So I am guessing we can sync at branch level.


 http://stackoverflow.com/questions/3907162/svn-error-x-isnt-in-the-same-repository-as-y-during-merge


 I am not a SVN admin.Just evaluating the products to recommend to my
 team.Please advise if I am wrong.

 Thanks in advance!
 Mani

Re: Performance issue with svn export [svn 1.8.11]

[Eric Johnson]

Hi Nouha,

Based on the relative size of the repositories, one might expect that the
larger repository would take about twice as long to export. So clearly
something is weird here.

You'll still need to provide more details:

   - Are the types of files in the two repositories different?
   - Are you running a virus scanner on the client?
   - Have you timed the command, to find out how much system, user, and
   real time is being spent?
   - What command are you using to export? (Are you exporting from a
   working copy, or directly from the server?)
   - What OS  version thereof are you using on the client?
   - Have you observed the problem with other clients / OSes?
   - Does an export take the same time as a checkout?
   - Have you tried doing a export of the repository on the server? Does it
   show the same time discrepancy?

Somehow, you need to establish enough information to identify whether the
source of the problem is the server, the client, the network, or the
protocol.

For example, the client could be running a virus scanner that goes nuts for
your 30K files repository. Or it could be that something is unreliable
about your network, but only manifests itself with a few files from your
30K repository.

Eric.


On Fri, May 29, 2015 at 7:37 AM, Nouha Terzi terzi.no...@gmail.com wrote:

 Hello Eric,

 Many thanks for your answer.

 What's the client on which you're running the svn export command?
  I tested with 2 svn clients: 1.6.11 and 1.8.8 from an RH 5 server and
 got the same response time for both export

 Are you doing the export across the network, or on the same machine
 hosting the repository?
  It is thru Network. And the  2 repositories are hosted on the same
 remote svn server.
  My server and my client are hosted on the same WAN-intranet.

 When the export is done, how much disk space is taken by the export (in
 both cases)?
  121M for the repo having 30k files and 68M for teh second one.

 Please note that we are using http protocol not svn thru ssh.

 Thank you for valuable support in advancE.

 regards,
 Nouha


 2015-05-28 21:08 GMT+01:00 Eric Johnson e...@tibco.com:

 Looks like nobody has responded yet. I've certainly not encountered that
 behavior.

 I think you'll need to provide more information. The problem could stem
 from so many places. Could be, for example, that you've got a virus
 scanner, and when you export the 30K files, you're exporting files that
 draw more attention from a virus scanner.

 What's the client on which you're running the svn export command? Are you
 doing the export across the network, or on the same machine hosting the
 repository? When the export is done, how much disk space is taken by the
 export (in both cases)?

 Eric.

 On Tue, May 26, 2015 at 9:05 AM, Nouha Terzi terzi.no...@gmail.com
 wrote:

 Hello all,

 we are deploying svn 1.8.11 on our server Rhel 6.6.
 We are facing some issue within svn export.
 it seems that it has some perf limitation when dealing with a huge
 number of files.

 we have this delay when doing an svn export url and the target has:

 less than 20k files export  = ~ 1 minute

 more than 30k files export   1 hour



 Is it a known issue? Has someone encouter thsi behavior?


 thnak you for your valuable support.


 regards,

 Nouha

Re: Performance issue with svn export [svn 1.8.11]

[Eric Johnson]

Looks like nobody has responded yet. I've certainly not encountered that
behavior.

I think you'll need to provide more information. The problem could stem
from so many places. Could be, for example, that you've got a virus
scanner, and when you export the 30K files, you're exporting files that
draw more attention from a virus scanner.

What's the client on which you're running the svn export command? Are you
doing the export across the network, or on the same machine hosting the
repository? When the export is done, how much disk space is taken by the
export (in both cases)?

Eric.

On Tue, May 26, 2015 at 9:05 AM, Nouha Terzi terzi.no...@gmail.com wrote:

 Hello all,

 we are deploying svn 1.8.11 on our server Rhel 6.6.
 We are facing some issue within svn export.
 it seems that it has some perf limitation when dealing with a huge number
 of files.

 we have this delay when doing an svn export url and the target has:

 less than 20k files export  = ~ 1 minute

 more than 30k files export   1 hour



 Is it a known issue? Has someone encouter thsi behavior?


 thnak you for your valuable support.


 regards,

 Nouha

Re: SVN write through proxy out off sync

[Eric Johnson]

Looks to me like the sync failed at one point, and there's a pending lock
on the mirror repository. Remove the lock and try the sync again.

On Fri, May 15, 2015 at 3:10 AM, Mustafa Karci m...@theipcompany.nl wrote:

 Today ore svn mirrror got out off sync. The setup is as the headline
 describes. We have setup a mirror that does only read actions and write
 actions are committed to the master SVN server.

 So on the mirror we have in the /etc/http/conf.d/mirror.conf file. this
 has 2 locations created. The private branch that redirects all writes to
 the master SVNMasterURI and a second Where the sync from master is send
 to.

 And yes, all hook scrip are executable. So the problem is : Some in 6
 mounts the mirror would got out off sync because the locking mechanism was
 in please. So normally We would do a

 svn propdel --revprop -r0 svn:sync-lock http://mirror/svn-proxy-sync
 svnsync sync http://mirror/svn-proxyn-sync file:///home/master/svn/private

 But now doing a svnsync sync http://mirror/svn-proxyn-sync 
 file:///home/master/svn/private
 we get an error messages like :

  svnsync: DAV request failed; it's possible that the repository's pre-
revprop-change hook either failed or is non-existent
  svnsync: At least one property change failed; repository is unchanged
  svnsync: Error setting property 'sync-lock':
  Can't find a temporary directory: Internal error

 here are the config file:

 master SVN

  Location /svn/master 
   DAV svn
   SVNListParentPath Off
   SVNPath /home/master/svn/private
   #SVNParentPath /var/www/svn
   AuthType Basic
   AuthName BLA BLA
   AuthUserFile /home/master/svn/etc/htpasswd
   AuthzSVNAccessFile /home/master/svn/etc/private.access
   Require valid-user
  /Location

 Mirror write through proxy

  Location /svn/mirror 
DAV svn
SVNListParentPath Off
SVNPath /home/mirror/svn/private
SVNMasterURI http://svnmaster/svn/master
#SVNParentPath /var/www/svn
AuthType Basic
AuthName BLA BLA BAL
AuthUserFile /home/mirror/svn/etc/htpasswd
AuthzSVNAccessFile /home/mirror/svn/etc/private.access
Require valid-user
  /Location
 Location /svn-proxy-sync 
DAV svn
SVNListParentPath Off
SVNPath /home/mirror/svn/private
Order deny,allow
Deny from all
Allow from xxx.xxx.xxx.xxx/Location

 Also when we tried to do a

 svnsync init commando we are getting the same output


 --
 Mustafa Karci


 The IP Company
 Kruisweg 609
 2132 NB  Hoofddorp
 The Netherlands

 Website: www.theipcompany.nl
 Phone number: 085 1119158
 Direct phone number: 085 1119158

Re: Reoganizing svn structure and error shares no common ancestry

[Eric Johnson]

You can't do a reorg, but you could possibly recreate the branches.

Perhaps a pain, but you certainly could build a script that iterates
through the changes on your branch, and recreates them by taking advantage
of Subversion's three way merge functionality (using --ignore-ancestry!).

More specifically:

1) identify the point in history on the old branch where it exactly matched
trunk

2) Create new branch from that point in time that you just identified

3) Do a log on the old branch, identifying each change that was applied to
the branch.

4) Checkout a working copy of the new branch

5) For each revision on the *old* branch, do a three way merge followed by
commit (make sure you're in the working copy for the new branch!):

svn merge --ignore-ancestry -r___:___ /branches/oldbranch

You'll need to walk through each revision in the old branch. Start with the
branch point revision # to first change revision #. Then first change
revision # to second change revision #. Etc.

Make sense?

Eric.



On Thu, Mar 19, 2015 at 4:34 AM, Buddy Butterfly buddy.butter...@web.de
wrote:


 thanks for explanation.
 Yes, indeed it looks like the branches have not been branched from trunk.
 So there is no way to reorg and get the old branches to be recognized as
 correct branches? I did a test and branched from the new trunk and copied
 that content of the old branch into it. Now the branch is detected as such
 and it can be switched to from trunk. But this means we would have to redo
 manually all branches and tags etc? I was hoping there is some other way.

 Am 18.03.2015 um 22:01 schrieb Bert Huijben:
 
  You can avoid the error by passing --ignore-ancestry to switch… but that
 doesn’t fix the ancestry problem
 
 
 
  What it tries to tell you is that the branches were not created from
 trunk.
 
 
 
  Usually you would
 
  * create trunk
 
  * apply some changes to trunk
 
  * copy that to a branch
 
  * apply some changes to trunk
 
  * copy that to a branch
 
  * update trunk….
 
  *…
 
 
 
  That way the branches share ancestry with trunk (and thereby with each
 other). Further updates on the branches are possible, but they still share
 (some) history, as they all originated from the original trunk.
 
 
 
 
 
  Your script says that you created the branches as new, so Subversion is
 right that the branches don’t share ancestry with trunk. Usually you only
 want to switch between related branches. (A common error is to branch to
 the wrong directory level. This is caught by this check). The
 --ignore-ancestry override works for those cases that there is no shared
 ancestry… but this might tell you that everything will be deleted and
 checked out clean (depends on more things), so perhaps in some cases just
 deleting and a clean checkout may be faster.
 
 
 
  Bert
 
 
 
  *From:*Eric Johnson [mailto:e...@tibco.com e...@tibco.com]
  *Sent:* dinsdag 17 maart 2015 23:14
  *To:* buddy.butter...@web.de
  *Cc:* users@subversion.apache.org
  *Subject:* Re: Reoganizing svn structure and error shares no common
 ancestry

 
 
 
  Does switching to a new branch work before the reorganization that you
 did?
 
 
 
  What version of Subversion are you using?
 
 
 
  Can you reproduce the problem with a mock version of your repository?
 
 
 
  When you do an svn log of your new branch, does the history go back to a
 common revision with the new trunk? Likewise, with your new trunk, does an
 svn log show a common revision with the branch?
 
 
 
  Eric
 
 
 
 
 
  On Mon, Mar 16, 2015 at 3:18 AM, Buddy Butterfly buddy.butter...@web.de
 mailto:buddy.butter...@web.de buddy.butter...@web.de wrote:
 
 
  Hi,
 
  finally we would like to restructure our badly structured svn repo.
  Over time a lot of stuff flew into this repo. I have used kdesvn for
  moving the trees online in the repo. kdesvn does a copy and delete
  when moving. I have also tried to use a svn move. Steps were as
 follows:
 
  1. Created a new repo path to the project.
  2. Created branches, tags and trunk below ist.
  3. Moved (like described above) original project below the new trunk.
  4. Similar like 3. for branches with creating the branches/branch
 and
 moving the old branches to the new ones.
  5. Checked out the new trunk.
  6. Tried to switch to one of the new branches.
 
  Step 6. always give the error switching not possible shares no
 common
  ancestry.
 
  The moving like described above is very convenient and would allow
 the reorg
  in an acceptable time frame. How is it possible to do this and
 create or
  manipulate the history such that a common ancester will be created?
 
  Do you propose another workflow to acomplish this in an easy way?
 
  Thanks a lot and cheers,
  Buddy
 
 
 

Re: Reoganizing svn structure and error shares no common ancestry

[Eric Johnson]

Does switching to a new branch work before the reorganization that you did?

What version of Subversion are you using?

Can you reproduce the problem with a mock version of your repository?

When you do an svn log of your new branch, does the history go back to a
common revision with the new trunk? Likewise, with your new trunk, does an
svn log show a common revision with the branch?

Eric


On Mon, Mar 16, 2015 at 3:18 AM, Buddy Butterfly buddy.butter...@web.de
wrote:


 Hi,

 finally we would like to restructure our badly structured svn repo.
 Over time a lot of stuff flew into this repo. I have used kdesvn for
 moving the trees online in the repo. kdesvn does a copy and delete
 when moving. I have also tried to use a svn move. Steps were as follows:

 1. Created a new repo path to the project.
 2. Created branches, tags and trunk below ist.
 3. Moved (like described above) original project below the new trunk.
 4. Similar like 3. for branches with creating the branches/branch and
moving the old branches to the new ones.
 5. Checked out the new trunk.
 6. Tried to switch to one of the new branches.

 Step 6. always give the error switching not possible shares no common
 ancestry.

 The moving like described above is very convenient and would allow the
 reorg
 in an acceptable time frame. How is it possible to do this and create or
 manipulate the history such that a common ancester will be created?

 Do you propose another workflow to acomplish this in an easy way?

 Thanks a lot and cheers,
 Buddy

Re: SVN commit does nothing

[Eric Johnson]

My next guess - make sure you don't have a firewall or other agent blocking
some of your HTTP traffic. Could be you're accidentally blocking some of
the requests being sent to Apache.

I mention that, because that would be consistent with the client waiting
for the response, and the server not thinking there's anything to be done.

Eric.

On Tue, Mar 10, 2015 at 9:26 AM, pascal.sand...@freescale.com 
pascal.sand...@freescale.com wrote:

  Hi Eric

 Thanks for your answer.



 The repository are well created under the location ___/svn and I can
 access them through http, that’s fine.

 Error log from apache does not show anything.

 I added svn logging in httpd.conf (following this
 http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.logging),
 I see read operations being done (update, or show log from tortoise) but
 not the commit.

 I tried to checkout and commit directly on the machine (as the same user
 running apache) using file:/// and commit works!

 That’s a first step but I don’t see what is wrong then…



 Thanks

 Pascal



 *From:* Eric Johnson [mailto:e...@tibco.com]
 *Sent:* Tuesday, March 10, 2015 4:32 PM
 *To:* Sandrez Pascal-B09824
 *Cc:* users@subversion.apache.org
 *Subject:* Re: SVN commit does nothing



 After you have created repositories, do you see them listed when you
 browse to the /svn location in your browser. Do the error logs for
 Apache show anything? Have you checked into all the logging options for
 Subversion + Apache (sorry, don't have the link handy from my phone)?



 Also, try checkout and commit directly on the machine (as the same user
 running Apache), using file:/// URLs, and see if that reports anything
 that gives you a clue as to whether it is working. Or does it just work?



 Eric


 On Mar 10, 2015, at 7:53 AM, pascal.sand...@freescale.com 
 pascal.sand...@freescale.com wrote:

  Hi



 I recently installed svn module (1.8.11) for apache (2.2.24). I compiled
 successfully everything without issue but I can’t have it working properly,
 I need help of advanced users.

 I can create repository with svnadmin or copy repository from existing
 installation. I didn’t set any rights limitation for now to be able to
 easily test installation.

 Repository checkout or update is working fine using tortoise or command
 line client. Repository read through web browser is also working fine.



 BUT commit does nothing. When I try to commit existing or new file, from
 tortoise or command line, commit starts and is never done. It seems to be
 doing the commit until timeout occur (few minutes) or I cancel it. I don’t
 have any error message, nothing to debug. In httpd access log I see an
 OPTION request, that’s all. Nothing in error log.



 My configuration is like this:



 LoadModule dav_module lib/httpd/modules/mod_dav.so

 LoadModule dav_fs_module lib/httpd/modules/mod_dav_fs.so

 LoadModule dav_svn_module libexec/mod_dav_svn.so

 LoadModule authz_svn_module   libexec/mod_authz_svn.so



 DavLockDB /opt/amon/var/DavLock



 Location /svn

 DAV svn

 SVNParentPath /opt/amon/var/www/svn

 SVNListParentPath On

 /Location



 Apache user and group is the same as user creating the repository.



 After few days searching I don’t see anything else to do, what could I
 check now?



 Thanks for your help!



 Regards

 Pascal

Re: SVN commit does nothing

[Eric Johnson]

After you have created repositories, do you see them listed when you browse
to the /svn location in your browser. Do the error logs for Apache show
anything? Have you checked into all the logging options for Subversion +
Apache (sorry, don't have the link handy from my phone)?

Also, try checkout and commit directly on the machine (as the same user
running Apache), using file:/// URLs, and see if that reports anything that
gives you a clue as to whether it is working. Or does it just work?

Eric


On Mar 10, 2015, at 7:53 AM, pascal.sand...@freescale.com 
pascal.sand...@freescale.com wrote:

  Hi



I recently installed svn module (1.8.11) for apache (2.2.24). I compiled
successfully everything without issue but I can’t have it working properly,
I need help of advanced users.

I can create repository with svnadmin or copy repository from existing
installation. I didn’t set any rights limitation for now to be able to
easily test installation.

Repository checkout or update is working fine using tortoise or command
line client. Repository read through web browser is also working fine.



BUT commit does nothing. When I try to commit existing or new file, from
tortoise or command line, commit starts and is never done. It seems to be
doing the commit until timeout occur (few minutes) or I cancel it. I don’t
have any error message, nothing to debug. In httpd access log I see an
OPTION request, that’s all. Nothing in error log.



My configuration is like this:



LoadModule dav_module lib/httpd/modules/mod_dav.so

LoadModule dav_fs_module lib/httpd/modules/mod_dav_fs.so

LoadModule dav_svn_module libexec/mod_dav_svn.so

LoadModule authz_svn_module   libexec/mod_authz_svn.so



DavLockDB /opt/amon/var/DavLock



Location /svn

DAV svn

SVNParentPath /opt/amon/var/www/svn

SVNListParentPath On

/Location



Apache user and group is the same as user creating the repository.



After few days searching I don’t see anything else to do, what could I
check now?



Thanks for your help!



Regards

Pascal

Re: How to configured Submin with svn ?

[Eric Johnson]

Hi Mohsin,

Your questions don't include enough specificity to make them easy to answer.

Also, rather than asking for someone's time to help (in which case, you
might be best helped by finding a commercial support option), ask for
information. The more specific the question, the better.

That is, rather than kindly guide me how to do this, perhaps does anyone
have a link to installing/configuring this specific configuration.

Or, even better, I'm seeing failure ___. Googling found three possible
solutions _, _, and . However, none of those fixes worked,
although _ seemed appropriate to my situation.

Eric

On Fri, Mar 6, 2015 at 8:35 AM, Mohsin mohsinchan...@gmail.com wrote:

 Hello,

 Every one have precious time no body wants to waste others time if someone
 is posting or requesting for help it's does't means he intentionally want
 to
 disturb you. IF you are too busy kindly don't reply on my posts there are
 many good people here which can help me i know i am not expert in svn like
 you or others people here i am just svn user but try to understand new
 features of svn to grasp on svn.

 FYI
 I have already installed submin on my server but reason for help was
 configuration which i was not able to run successful submin. Don't
 discourage others if you can't help him.


 Mohsin



 --
 View this message in context:
 http://subversion.1072662.n5.nabble.com/How-to-configured-Submin-with-svn-tp192373p192391.html
 Sent from the Subversion Users mailing list archive at Nabble.com.

Re: variables in AuthzSVNAccessFile - a shortcut?

[Eric Johnson]

So far as I know, there are no variables in the file. If you've got any
needs that lead to wanting variables (other than the already supported
groups), then perhaps you want to generate the file? That's an approach we
take at my company.

If you take the approach of generating the file, then I don't think there
are any per-request variables that matter.

As for your specific idea, it looks like you want to have per-user
folders in repositories. Since those folders aren't created by magic,
perhaps you want to reserve their creation to someone like an
administrator, and catch their creation in a post-commit script, and
regenerate your access file?

Eric.


On Thu, Feb 26, 2015 at 8:47 AM, lejeczek pelj...@yahoo.co.uk wrote:

 hi everybody

 as a novice I understand I'm looking for shortcuts, probably being not the
 first one I'd have this question:

 does Subversion implement any variables in it's configuration?
 first case to exercise this scenario would be AuthzSVNAccessFile
 could one have

 [REPO_NAME:/_$user]
 _$user = rw

 naturally I'm thinking here of login/logged in user, via http
 many thanks.

Re: copy multiple folders from one repository to another repository at server using subversion

[Eric Johnson]

As a previous response suggested, upgrade your Subversion first, and then
try the dump/filter/load.

Eric.

On Mon, Feb 2, 2015 at 5:56 AM, gangadhar jannu gangadhar@gmail.com
wrote:

 Hi,

 Thanks for your detailed explanation.

 I've already tried what you suggested but something went wrong in that
 process.

 The actual scenario is:
 I have created 'allProj' repository and it is operating since 2013.
 *allProj *contains 120 folders. Out of 120 projects currently 20 projects
 are required.
 So I'm trying to create another repository 'reqProj' which contains those
 20 projects out of 120 projects.

 I've tried *dump - filter - load *method already.
 So I'm able to load only 18 projects Out of 20 projects (2 projects were
 missing even though I tried to load all 20 projects dump).

 What exactly I tried is:
 *dump: *svnadmin dump file:///var/lib/svn/allProj  allProj.dump
 cat allProj.dump | svndumpfilter include Projects/projectB
 Projects/projectD Projects/projectE  reqProj.dump
 svnadmin create file:///var/lib/svn/reqProj
 svnadmin load fil:///var/lib/svn/reqProj  reqProj.dump

 Everything it is showing is fine but still I'm not gettting all the
 folders. Out of 20 projects I'm getting 18 projects.

 Is there any alternative method or am I doing wrong ...?

 I've searched a lot on this topic and I found nothing on how to move
 multiple folders from one repository to another repository

Any know of a Subversion sync program that I could run as a daemon?

[Eric Johnson]

I've been setting up a mirror. I've got the mirror up and running, and
properly configured.

Problem: Now I need to trigger a sync whenever a commit comes in. In
principle, this is easy - I just write a hook script and call svnsync.

In practice, I have a bunch of requirements  desired features that make a
simplistic solution problematic

   - Asynchronous - I don't want the person doing the original commit
   sitting around waiting for their commit to be broadcast to all the mirrors.
   I'm potentially looking at long delays either to distance or network pipe,
   and occasional large commits that take long enough even to send to the
   server in the first place.
   - Retry on fail - I want to be able to retry on fail, in case the
   problem is a transient network issue
   - Email on fail - I want an email if the sync fails
   - Logging - information to log files on both success and failure.

Are there any open source tools out there already that do that?

Eric.