SVN over NFS/CIFS (Windows client to Linux server)

[Johnston, Tim]

We are using SVN 1.7 repositories which are checked out to a Linux file server. 
Users access their files via TortoiseSVN (1.7.15, which is also built against 
SVN 1.7.x), either via CIFS or NFS.

When accessing via CIFS (with the Linux side serving via Samba), we 
occasionally encounter SQLite database corruption. My understanding is that 
this is caused by differences between the Windows and POSIX locking 
implementations (inside libsvn).

When accessing via the official Windows NFS client (talking to a Linux NFS 
server), we are unable to even check out a repository via TortoiseSVN. It fails 
immediately with a locking error.

I find it very difficult to search for this issue, partly because SVN has an 
unrelated "file locking" feature, and partly because users have posted about a 
number of other simpler SQLite corruption issues with SVN..

So my question is this: what is the current state of SVN clients on Windows, 
accessing a Linux file share, with respect to file locking / SQLite etc?
Are there options for this problem with newer Windows (Tortoise)SVN client 
versions? Or is this problem still the same in the newest versions?

Any recommendations would be appreciated!

Re: SVN over NFS/CIFS (Windows client to Linux server)

[Daniel Sahlberg]

Den tis 18 juni 2024 kl 17:49 skrev Johnston, Tim <
tim.johns...@christiedigital.com>:

> We are using SVN 1.7 repositories which are checked out to a Linux file
> server. Users access their files via TortoiseSVN (1.7.15, which is also
> built against SVN 1.7.x), either via CIFS or NFS.
>

That is a really old version, with an equally old version of SQLite.


>
> When accessing via CIFS (with the Linux side serving via Samba), we
> occasionally encounter SQLite database corruption. My understanding is that
> this is caused by differences between the Windows and POSIX locking
> implementations (inside libsvn).
>

I'm not sure if it is Subversion or SQLite that is having the most problems
but general wisdom is to not store a working copy on a network share.


>
> When accessing via the official Windows NFS client (talking to a Linux NFS
> server), we are unable to even check out a repository via TortoiseSVN. It
> fails immediately with a locking error.
>
> I find it very difficult to search for this issue, partly because SVN has
> an unrelated "file locking" feature, and partly because users have posted
> about a number of other simpler SQLite corruption issues with SVN..
>
> So my question is this: what is the current state of SVN clients on
> Windows, accessing a Linux file share, with respect to file locking /
> SQLite etc?
> Are there options for this problem with newer Windows (Tortoise)SVN client
> versions? Or is this problem still the same in the newest versions?
>

I don't think any significant work has been done towards supporting working
copies on network shares. Subversion relies on proper file locking and if
this fails (which I assume is the cause of your trouble) then all bets are
off.

SQLite goes quite far in recommending to use another database engine if
over-the-network functionality is required:
https://www.sqlite.org/useovernet.html

These are the two FAQ items I can find mentioning problems storing a
working copy / sqlite database on a network share:
https://tortoisesvn.net/faq.html#wconshare
https://www.sqlite.org/faq.html#q5

Our own FAQ suggests that storing a working copy on an NFS share should be
fine, but I presume the Windows NFS client is not as well behaved as Unix
NFS clients.
https://subversion.apache.org/faq.html#nfs


>
> Any recommendations would be appreciated!
>

Why do you need to store the working copy on a network share? Can you
adjust your workflow to make sure every user has their own working copy,
stored on local disk?

Kind regards,
Daniel

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Paul Leo]

Once again thanks for all your past help

The new repository is up and running. But we haven't cut over yet.

I have asked folks to commit all changes that they would like included 
in new repo.


I'm using svnsync multiple times per day, with no issues.

There's a good chance that DNS name may not be able to stay the same.

TortoiseSvn is used almost exclusively for commits. and checkouts.

If I try a relocate in TortoiseSVN, I get an error saying the uuid of 
the new server is different than the WC of the local repo.   I presume 
this is because of the DNS name change.


I've done some searching and have followed a suggestion and edited the 
wc.db and replaced old server uuid with new server uuid, tried the 
relocate command again and things seem to be working and pointing to new 
server.


I also know that doing a new checkout from the new server may be the 
simplest solution. But perhaps some folks will not commit all of their 
changes before switchover because they are not ready.


The reason I am posting here instead of TortoiseSVN is I would like to 
know whether it would be safer to have folks just do a new checkout from 
new server once old server is shutdown, (and diff folders if needed) 
instead of trying relocate, or should I have them edit the wc.db and 
replace or try and change the uuid on the new server to match the old one.


I've done some reading in the SVN-redbook, but am concerned that perhaps 
there are things that I may be missing because the redbook may be out of 
date.


I've also read of some issues of changing uuid on server, so if that is 
what should be done, I would like specific instructions/suggestions.


Thanks,

Paul

On 6/7/2024 10:17 AM, Paul Leo wrote:


Tak Daniel.

Appreciate the detailed response.  I have asked for the two hooks that 
seemed to be copied from the templates.


If the dump doesn't work, I may have them try and tar up the whole 
repo directory.


I do have the auth tables, and will try them once repo is up and 
running, otherwise, I will create new user/passwords.  The community 
is small enough so that this should not be an issue.


On 6/7/2024 2:16 AM, Daniel Sahlberg wrote:
Den tors 6 juni 2024 kl 21:40 skrev Paul Leo 
:


We need to migrate an SVN repository from CentOS 7, Subversion
1.94 to
Ubuntu 24.04, SVN 1.14.3.

We don't have any login access to the current server.

The current hosting server plans to perform an SVN dump of the
repository, and make it available through something like Google
Drive.

We would obtain the dump file and then use svnadmin load,
importing the
repository.


As others have already pointed out svnadmin dump/load or svnrdump are 
the main candidates. Another option is to have your hosting provider 
pack the repository folder in its entirety (to a tar.gz) which you 
could unpack on the new server and use as-is.



There are only a few hooks that are currently used.  The main one
being
to force a commit message when committing.


Although the dump file does NOT contain any hook scripts. These need 
to be extracted from the [/path/to/repo]/hooks directory on the 
server. If you don't have access to the server yourself (and the 
hosting provider doesn't have a web interface to manage the hook 
scripts) you need to ask them to copy the scripts manually. (If your 
hosing provider choose to pack the complete repository folder the 
hooks are of course included).



We will use Apache httpd and basic authentication for committing to
repository, as in done currently


The authentication (login) and authorization (permissions) are not 
included in the dump file either. If you want to keep the 
username/passwords the hosting provider need to give you these files 
as well (path and filename depends on the setup in Apache httpd).



We would change DNS to new server IP.


I assume you mean you use a DNS entry 
(https://svn.example.com/repos/.. 
.) which will be updated. In this 
case you should not need to do anything. If you change some part of 
the URL (either new hostname, adding SSL/TLS or the path to the 
repositories) you need to run


svn relocate [new_url]

in each working copy.


I've read through the svnbook, and the above seems plausible.

I am just wondering if anyone has some guidance and suggestions,
since
we are making a significant jump to newer version of SVN.


There should be no major difference.


Thanks for your help


Kind regards,
Daniel

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Ryan Carsten Schmidt]

On Jun 18, 2024, at 16:19, Paul Leo wrote:
> 
> If I try a relocate in TortoiseSVN, I get an error saying the uuid of the new 
> server is different than the WC of the local repo.   I presume this is 
> because of the DNS name change.

The DNS name has nothing to do with the UUID.

If the new repository is *identical* to the old repository (all of the old 
repository's revisions were copied and they have exactly the same contents) 
then you will want the UUIDs to be the same so that you can relocate existing 
working copies. The old repository's UUID is automatically copied to the new 
repository when you import a dumpfile into a newly created repository unless 
you use a command line flag to tell it to generate a new UUID.

On the other hand, if the new repository differs at all from the old one (for 
example you filtered out revisions or you imported the dumpfile into an 
existing non-empty repository) then the new repository UUID must be different 
and relocation is not possible and new working copies must be checked out.

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Paul Leo]

Thanks Ryan.  I guess I can't believe everything on the internet, where 
I got the DNS name story


The commands used to create and sync the repo were:

svnsync initialize file:///srv/svn_repos/ibis/main 
https://svn.ibisph.org/svn/main


svnsync synchronize file:///srv/svn_repos/ibis/main 
https://svn.ibisph.org/svn/main


I didn't receive any errors during the sync

So I assumed that the uuid would be the same but they are different.

Perhaps the safest way for folks to switch would be to create a new folder

Checkout from new server

Diff with old folder from old server, and bring over any changes folks 
want and then commit to new server.


Thanks

On 6/18/2024 4:05 PM, Ryan Carsten Schmidt wrote:

On Jun 18, 2024, at 16:19, Paul Leo wrote:

If I try a relocate in TortoiseSVN, I get an error saying the uuid of the new 
server is different than the WC of the local repo.   I presume this is because 
of the DNS name change.

The DNS name has nothing to do with the UUID.

If the new repository is *identical* to the old repository (all of the old 
repository's revisions were copied and they have exactly the same contents) 
then you will want the UUIDs to be the same so that you can relocate existing 
working copies. The old repository's UUID is automatically copied to the new 
repository when you import a dumpfile into a newly created repository unless 
you use a command line flag to tell it to generate a new UUID.

On the other hand, if the new repository differs at all from the old one (for 
example you filtered out revisions or you imported the dumpfile into an 
existing non-empty repository) then the new repository UUID must be different 
and relocation is not possible and new working copies must be checked out.