Re: subversion exception on subversion repository viewer

[Johan Corveleyn]

On Wed, Apr 15, 2020 at 1:42 PM Brian Thomas 
wrote:

> We're long time svn users. We recently upgraded from
>
> C:\Windows\System32>svn --version
> svn, version 1.9.5-SlikSvn (SlikSvn/1.9.5)
>compiled Dec  2 2016, 22:16:15 on x86_64-microsoft-windows6.2.9200
>
> to this:
>
> C:\Program Files\TortoiseSVN>bin\svn --version
> svn, version 1.13.0 (r1867053)
>compiled Oct 31 2019, 20:41:49 on x86-microsoft-windows
>
> Now when I open the TortoiseSVN repository browser and select a project
> folder in the left-hand pane, then r-click a file in the right-hand pane
> and select Edit then the selected file opens in Notepad.
> But on the second attempt—if I r-click a *different* file in the same
> folder in the right-hand pane I get a dialog containing this text:
>
> Error: 'C:\Users\thomasb\AppData\Local\Temp' is already a working copy for
> a different
> Error:  URL
> Completed!:
>
>
> and then I get this Exception dialog:
>
> ---
> 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
> https://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.13.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
>  line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
> ---
> OK
> ---
>
>
> This defect has been reported already (in 2018!) but there's been no fix
> as far as I can tell.
>
>
> This is a regression since 1.9 where this error did not occur.
>


Hi Brian,

Heh, this error was just reported twice on this mailinglist two days ago
:-). As I replied already on those other posts:

This is a bug specific to TortoiseSVN (Windows GUI for SVN, a separate
project from the Subversion project, with its own mailinglists:
https://tortoisesvn.net/community.html).

The bug seems to be fixed already:
https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/tortoisesvn/_wyo1iQIc1c/HAybYPkjCQAJ

But unfortunately it's not yet part of a new TSVN release (1.13.1 is
currently the latest one). Perhaps you could use a nightly build of
TortoiseSVN if you need this fix (scroll to the bottom of
https://tortoisesvn.net/downloads.html).

-- 
Johan

Re: svn:ignore of checked in files and commit

[Johan Corveleyn]

On Wed, Apr 15, 2020 at 2:03 PM Attila Kinali  wrote:
>
> On Wed, 15 Apr 2020 13:53:07 +0200
> Branko Čibej  wrote:
>
> > I don't remember svn:ignore *ever* working the way you describe. Can you
> > tell us which version of Subversion you were using? Are you absolutely
> > sure it wasn't modified to behave as you describe?
>
> That was like 10-15 years ago. I don't remember which version we
> used back then.
>
> > Like I said, it did not change. Files that are already
> > version-controlled cannot be ignored. This was part of the original
> > svn:ignore design spec, and the behaviour is actually based on .cvsignore.
>
> Hmmm.. could it be that we were relying on a bug?
>
> > > Is there a workaround that we can use?
> >
> > Sure, don't commit the files that you don't want in the repository.
> > Instead, create a template that each user can rename to an (ignored)
> > local name.
>
> Yes, but mistakes happen. This is a project we are doing together with
> a bunch of computer scientists. These are not computer savy people!
> I'm glad we are using any SCM in the first place and not some Dropbox
> with zip files or something.
>
> Seem's like I have to think about changing our workflow..

FWIW, the behavior you want is a very old feature request that
unfortunately never got implemented:

https://issues.apache.org/jira/browse/SVN-2858 (Support file property
which indicates that commit must be manually forced)

Some of us know it as the "svn:hold" property.

I think this still could be implemented if someone stepped up to do it
(starting by dusting off the old design docs and discuss approaches on
dev@). But it won't be easy, because there is a lot of interaction
with other existing features.

-- 
Johan

Re: Preferred Subversion 1.13 MPM

[Johan Corveleyn]

On Tue, Apr 14, 2020 at 10:25 AM Carmen Alzzer  wrote:
>
> helo friends,
> while this is still hot on here - can you please tip in how your MPM are
> handled? also if you have thoughts upon reading my setup, i would be
> delighted to hear from you :)
>
> cheers
> Carmen

Hi Carmen,

[ Sidenote: we prefer "bottom-posting" or "inline replying" on this list. ]

I have never looked at tweaking the MPM myself, and I have not yet
seen much discussion about it here. We're using the defaults of our
distribution (we use a CollabNet package of SVN, which includes httpd
2.2.23), which is prefork (with default settings). We're running it on
a VM with 4 Intel Xeon CPU's and 8 GB RAM, running Ubuntu 16.04. I
think the MPM will not be a big performance factor in most cases. IMHO
the things with the most impact on performance are not MPM-related
(and some are more client related). So, following Stefan, I would
suggest first making sure the "known performance knobs" are in order.
I'll try to give you "my list" here below.

In my experience, the most important things for SVN performance are:

Server side:
- httpd config:
MaxKeepAliveRequests 1 (or higher, we use 2) [1]
SVNInMemoryCacheSize 131072 (=128 MB -- or higher if you have
enough RAM), or some suitable value [2]
Cache authentication results (LDAP caching) (though I believe
this is less important if KeepAlive works well)
- If you don't need path-based authorization, disable it
(SVNPathAuthz off). If you have to use path-based authz, try
"SVNPathAutzh short_circuit" [3].
- FSFS back-end must be on fast storage, accessible by the server
as a local disk (not NFS / SMB mounted -- that's way too slow)
- Use FSFS format 8 with lz4 compression, and do a full dump &
load to this format if you can. (see [4] for a step-by-step guide)
- 'svnadmin pack' your repositories regularly (we use a nighly
cron job for this)
- If you have problems with commit performance, check your hook
scripts (start-commit, pre-commit, post-commit) for any custom code
that could be slowing things down too much (be very careful if you
loop over all changes in a commit, and do $stuff for every modified /
added / deleted file ... this scales with the size of your commit, so
make sure $stuff is as fast as possible, and avoid unnecessary work
(early-exit wherever you can)). If you're not sure, try to inject some
measurement code in your hook scripts [5].

Client side:
- Make sure they use recent clients! At least 1.10, preferably
even the latest (1.13).
- If a working copy acts really slow, ask them to run "svn
cleanup" (cleaning up the pristine store, and most importantly fixing
the timestamps of the files in the svn metadata). This is especially
important if they have copied over their (large) working copy from one
disk to another (depending on how this is done, this gives all files a
new lastmod-time, which makes the working copy very slow because svn
cannot use its metadata anymore as a shortcut to see if a file was
modified ... it has to read + checksum every file on many operations).
- Avoid using working copies on networked drives (NFS, CIFS, ...).
This can be really slow.
- If you really must use a networked location for your working
copy, try if it helps if you put "exclusive-locking = true" in the
[working-copy] section of the ~/.subversion/config (*nix) or
%APPDATA%/Subversion/config (Windows). [6]

Client-Server network:
- Be very wary of proxies etc. If you're running a corporate
installation, try to arrange that your clients can connect directly to
the svn server.
- On a LAN, of course wired works best (1 Gbit, or even 100 Mbit).
But wireless (if enough capacity) works fine too. These days, most of
our users are working from home over VPN, and that works very well
too.

[1] https://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
[2] 
https://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning
[3] 
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.ref.mod_dav_svn
[4] https://subversion.apache.org/faq.html#dumpload
[5] I'm using this helper code in my pre-commit hook (in Bourne shell):

[[[
DEBUG=1
logStart()
{
if [ $DEBUG ]
then
START_DATE=`date +'%F %T'`
START=`/usr/local/perl/bin/perl -MTime::HiRes -e 'print
Time::HiRes::gettimeofday.""'`
AUTHOR=`$SVNLOOK author $REPOS -t $TXN`
CHANGED=`$SVNLOOK changed $REPOS -t $TXN`
export CHANGED # Export so it can be reused (other scripts
check for this variable)
NR_CHANGES=`echo "$CHANGED" | wc -l`
fi
}

# logEndAndExit $exitCode
# Logs the end of the script with timing information, and exits with $exitCode
logEndAndExit()
{
EXIT_CODE=$1
if [ $DEBUG ]
then
ELAPSED=`/usr/local/perl/bin/perl -MTime::HiRes -e 'printf
("%.3f", Time::HiRes::gettimeofday - $ARGV[0])' $START`
# start-datetime end-datetime author 

Re: svn:ignore of checked in files and commit

[Mark Phippard]

On Wed, Apr 15, 2020 at 7:28 AM Attila Kinali  wrote:


> In the days of old, like several years back...
> When we had files that needed to be edited localy for each user/developer,
> we used to check them in normally, then set svn:ignore to ignore those
> files. This would result `svn commit` to ignore those files unless
> forced to by explicitly mentioning the filename (e.g., `svn commit
> ignoredfile`).
>
> Apparently this doesn't work anymore and svn commit happily still
> uses the ignored file and commits it... causing problems.
>


svn:ignore has never worked this way. The svn:ignore property only ignores
new unversioned files from being added. Perhaps you were using a GUI client
in the past that offered a feature like you describe? I doubt it would have
piggy-backed off the svn:ignore property though. More likely the GUI would
have added its own property.

Mark

Re: svn:ignore of checked in files and commit

[Attila Kinali]

On Wed, 15 Apr 2020 13:53:07 +0200
Branko Čibej  wrote:

> I don't remember svn:ignore *ever* working the way you describe. Can you
> tell us which version of Subversion you were using? Are you absolutely
> sure it wasn't modified to behave as you describe?

That was like 10-15 years ago. I don't remember which version we
used back then.

> Like I said, it did not change. Files that are already
> version-controlled cannot be ignored. This was part of the original
> svn:ignore design spec, and the behaviour is actually based on .cvsignore.

Hmmm.. could it be that we were relying on a bug?

> > Is there a workaround that we can use?
> 
> Sure, don't commit the files that you don't want in the repository.
> Instead, create a template that each user can rename to an (ignored)
> local name.

Yes, but mistakes happen. This is a project we are doing together with
a bunch of computer scientists. These are not computer savy people!
I'm glad we are using any SCM in the first place and not some Dropbox
with zip files or something.

Seem's like I have to think about changing our workflow..

Thanks a lot!

Attila Kinali
-- 
Science is made up of so many things that appear obvious 
after they are explained. -- Pardot Kynes

Re: svn:ignore of checked in files and commit

[Branko Čibej]

On 15.04.2020 13:27, Attila Kinali wrote:
> Hi,
>
> In the days of old, like several years back...
> When we had files that needed to be edited localy for each user/developer,
> we used to check them in normally, then set svn:ignore to ignore those
> files. This would result `svn commit` to ignore those files unless 
> forced to by explicitly mentioning the filename (e.g., `svn commit 
> ignoredfile`).

I don't remember svn:ignore *ever* working the way you describe. Can you
tell us which version of Subversion you were using? Are you absolutely
sure it wasn't modified to behave as you describe?



> Apparently this doesn't work anymore and svn commit happily still
> uses the ignored file and commits it... causing problems.
>
> Is there a specific reason this behaviour changed?

Like I said, it did not change. Files that are already
version-controlled cannot be ignored. This was part of the original
svn:ignore design spec, and the behaviour is actually based on .cvsignore.


> Is there a workaround that we can use?

Sure, don't commit the files that you don't want in the repository.
Instead, create a template that each user can rename to an (ignored)
local name.



> Shall I submit a bugreport for this?

It's not a bug.

-- Brane

subversion exception on subversion repository viewer

[Brian Thomas]

We're long time svn users. We recently upgraded from

C:\Windows\System32>svn --version
svn, version 1.9.5-SlikSvn (SlikSvn/1.9.5)
   compiled Dec  2 2016, 22:16:15 on x86_64-microsoft-windows6.2.9200

to this:

C:\Program Files\TortoiseSVN>bin\svn --version
svn, version 1.13.0 (r1867053)
   compiled Oct 31 2019, 20:41:49 on x86-microsoft-windows

Now when I open the TortoiseSVN repository browser and select a project folder 
in the left-hand pane, then r-click a file in the right-hand pane and select 
Edit then the selected file opens in Notepad.
But on the second attempt—if I r-click a different file in the same folder in 
the right-hand pane I get a dialog containing this text:

Error: 'C:\Users\thomasb\AppData\Local\Temp' is already a working copy for a 
different
Error:  URL
Completed!:



and then I get this Exception dialog:

---
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
https://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.13.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
 line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
---
OK
---



This defect has been reported already (in 2018!) but there's been no fix as far 
as I can tell.


This is a regression since 1.9 where this error did not occur.



[Logo]

Brian Thomas | Senior Developer

Kutana Ltd | The Old Mill, Mill St, Wantage, OX12 9AB
e: brian.tho...@kutana.co.uk | w: www.kutana.co.uk
m: +44 (0)7952 451 429 | p: +44 (0)333 202 0971

svn:ignore of checked in files and commit

[Attila Kinali]

Hi,

In the days of old, like several years back...
When we had files that needed to be edited localy for each user/developer,
we used to check them in normally, then set svn:ignore to ignore those
files. This would result `svn commit` to ignore those files unless 
forced to by explicitly mentioning the filename (e.g., `svn commit 
ignoredfile`).

Apparently this doesn't work anymore and svn commit happily still
uses the ignored file and commits it... causing problems.

Is there a specific reason this behaviour changed?
Is there a workaround that we can use?
Shall I submit a bugreport for this?

Thanks and chocolaty greetings!

Attila Kinali

-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.