Re: What's the status of changing UUIDs of repos in working copies?

[Daniel Shahaf]

Ryan Schmidt wrote on Wed, 13 Jul 2022 21:45 +00:00:
> [...] that way all your public users' working copies continue to work
> as before, and you would just need to check out new working copies for
> those hopefully fewer and more technically capable internal users who
> were using the formerly private server with its old UUIDs.

Or manually change the UUID in those working copies using sqlite3.

Re: [External] : Re: What's the status of changing UUIDs of repos in working copies?

[Trent Fisher]

On 7/13/2022 9:25 AM, Daniel Shahaf wrote:

Thorsten Schöning wrote on Mon, Jul 11, 2022 at 16:06:11 +0200:


Do you have any tips for the easiest possible change of the UUIDs?

It'll be a lot easier to set the repository's UUID to the one expected
by clients.  See «svnadmin setuuid».


This is what I do, I have svnsync replicas at another site for disaster 
recovery, and I change the UUIDs to match so that, in a disaster, I can 
flip the DNS alias and they can keep working transparently (of course, 
making the replica read-write is also needed, but that's a different, 
more complicated, subject).


trent...

Re: EXTERNAL - line 10866: assertion failed (svn_dirent_is_absolute(local_abspath))

[Daniel Sahlberg]

Den ons 13 juli 2022 kl 15:35 skrev Klaey Matthias LCPF-CH <
matthias.kl...@mt.com>:

> Hi Nathan,
>
> See my responses further below as [MK 2022-07-13: ].
>
> Not sure whether my email properly has the [In-Reply-To] filled-in to end
> up in https://lists.apache.org/thread/n5vo9kznz9z2gzwy7kym9nj5rl9fw8mw.
> As I am forced to use Outlook, and googling doesn't tell me how to achieve
> [In-Reply-To] in Outlook, I can only hope my response gets there.
>
> Best regards,
> Matthias
>
>
> -Ursprüngliche Nachricht-
> Von: Nathan Hartman 
> Gesendet: Donnerstag, 7. Juli 2022 16:40
> An: Klaey Matthias LCPF-CH 
> Cc: users@subversion.apache.org
> Betreff: Re: EXTERNAL - line 10866: assertion failed
> (svn_dirent_is_absolute(local_abspath))
>
> On Wed, Jul 6, 2022 at 10:56 AM Klaey Matthias LCPF-CH <
> matthias.kl...@mt.com> wrote:
> > I encounter the same exception as
> https://lists.apache.org/thread/cxtl57o416ctbbzb315yh6x11kqyn7k3, though
> likely with a different cause. In my case:
>
> (snip)
>
> >
> 'D:\Development\SVN\Releases\TortoiseSVN-1.14.3\ext\subversion\subversion\libsvn_wc\wc_db.c'
> >
> > line 10866: assertion failed (svn_dirent_is_absolute(local_abspath))
>
> We've seen various reports of this exact error on that exact line over the
> years and it would be nice to finally track down the cause(s).
> (One thing that could help is to make SVN report the path in question
> together with the error.)
> [MK 2022-07-13:
> In my case, the path is
> "\\Content".]
>
> > Environment:
> >
> > Windows 10 Enterprise 20H2 19042.1706
> > TortoiseSVN 1.14.3, Build 29387 - 64 Bit , 2022/04/08 19:31:22 SVN
> > repo on some enterprise server SVN working copy on a network drive (I
> > know this may sound strange but it’s where the issue happens)
> >
> >
> >
> > Repro steps:
> >
> > [TortoiseSVN > Commit] on a large folder of the working copy, i.e. the
> operation takes several minutes.
> > Undock of the laptop where the operation is taking place, i.e. the
> connection to the network drive temporarily gets lost è exception.
>
> Not sure if I understand correctly, but is the laptop being undocked while
> the commit is in progress? If so, I wouldn't expect anything to work
> correctly due to the disconnection. If it's being undocked after the commit
> is complete, what (if any) other steps do you take that lead to the error?
> [MK 2022-07-13:
> Yes, the laptop accidentally being undocked while the commit is in
> progress. However, as there also is WLAN, the network is only interrupted
> for the short moment to switch from LAN to WLAN. The exception happens when
> undocking, i.e. when loosing LAN connection.
> I understand this is not a typical use case, still I expect TSVN to handle
> such situation and issue a proper error message, rather than crashing.]
>

If I'm reading the code correctly, the path variable is for some reason
incorrect (it is not "absolute", with absolute is defined as starting with
\\ or X:\ (X being a drive letter A-Z), with the \ translated to /
internally in TSVN). I'm guessing that it is empty, since it doesn't make
sense that undocking would just make it loose the \\ or drive letter. I'm
not sure if this path is being supplied directly from TSVN or if it is
constructed within Subversion code, and I'm not sure if some code could be
added to check for an empty path when the network connection is lost.

However fast the network is reconnected there will always be a moment with
no network. The part of the code that assert is the part that is reading
the WC database on the network drive. In this case we are not even
communicating with Subversion code on the other end but we are relying on
Windows to provide us with access to the SQLite database file. So even if
the code would not assert, you might end up with a situation where Windows
is telling SQLite "sorry but that file is not available" (which in turn is
telling Subversion something similar).

Conceivably there could be a "retry" logic that wait for a little while and
retry every operation that could be interrupted but I think that will be a
significant amount of work, and I'm not sure that will even be considered
desirable.

All above being said, please also be aware of what TSVN and SQLite say
about storing WCs on network shares:
* https://tortoisesvn.net/faq.html#wconshare
* https://www.sqlite.org/faq.html#q5

Kind regards,
Daniel Sahlberg

AW: EXTERNAL - line 10866: assertion failed (svn_dirent_is_absolute(local_abspath))

[Klaey Matthias LCPF-CH]

Hi Daniel,

Thanks for elaborating. I agree this network disconnection issue is a truly 
minor one. At the same time Nathan mentioned several other occurrences of the 
same issue. So maybe the sum of all information eventually allows TSVN to get 
this exception handled for the more common use cases.

Best regards,
Matthias


Von: Daniel Sahlberg 
Gesendet: Donnerstag, 14. Juli 2022 16:48
An: Klaey Matthias LCPF-CH 
Cc: Nathan Hartman ; users@subversion.apache.org
Betreff: Re: EXTERNAL - line 10866: assertion failed 
(svn_dirent_is_absolute(local_abspath))

Den ons 13 juli 2022 kl 15:35 skrev Klaey Matthias LCPF-CH 
mailto:matthias.kl...@mt.com>>:
Hi Nathan,

See my responses further below as [MK 2022-07-13: ].

Not sure whether my email properly has the [In-Reply-To] filled-in to end up in 
https://lists.apache.org/thread/n5vo9kznz9z2gzwy7kym9nj5rl9fw8mw. As I am 
forced to use Outlook, and googling doesn't tell me how to achieve 
[In-Reply-To] in Outlook, I can only hope my response gets there.

Best regards,
Matthias


-Ursprüngliche Nachricht-
Von: Nathan Hartman mailto:hartman.nat...@gmail.com>>
Gesendet: Donnerstag, 7. Juli 2022 16:40
An: Klaey Matthias LCPF-CH mailto:matthias.kl...@mt.com>>
Cc: users@subversion.apache.org
Betreff: Re: EXTERNAL - line 10866: assertion failed 
(svn_dirent_is_absolute(local_abspath))

On Wed, Jul 6, 2022 at 10:56 AM Klaey Matthias LCPF-CH 
mailto:matthias.kl...@mt.com>> wrote:
> I encounter the same exception as 
> https://lists.apache.org/thread/cxtl57o416ctbbzb315yh6x11kqyn7k3, though 
> likely with a different cause. In my case:

(snip)

> 'D:\Development\SVN\Releases\TortoiseSVN-1.14.3\ext\subversion\subversion\libsvn_wc\wc_db.c'
>
> line 10866: assertion failed (svn_dirent_is_absolute(local_abspath))

We've seen various reports of this exact error on that exact line over the 
years and it would be nice to finally track down the cause(s).
(One thing that could help is to make SVN report the path in question together 
with the error.)
[MK 2022-07-13:
In my case, the path is 
"\\Content".]

> Environment:
>
> Windows 10 Enterprise 20H2 19042.1706
> TortoiseSVN 1.14.3, Build 29387 - 64 Bit , 2022/04/08 19:31:22 SVN
> repo on some enterprise server SVN working copy on a network drive (I
> know this may sound strange but it’s where the issue happens)
>
>
>
> Repro steps:
>
> [TortoiseSVN > Commit] on a large folder of the working copy, i.e. the 
> operation takes several minutes.
> Undock of the laptop where the operation is taking place, i.e. the connection 
> to the network drive temporarily gets lost è exception.

Not sure if I understand correctly, but is the laptop being undocked while the 
commit is in progress? If so, I wouldn't expect anything to work correctly due 
to the disconnection. If it's being undocked after the commit is complete, what 
(if any) other steps do you take that lead to the error?
[MK 2022-07-13:
Yes, the laptop accidentally being undocked while the commit is in progress. 
However, as there also is WLAN, the network is only interrupted for the short 
moment to switch from LAN to WLAN. The exception happens when undocking, i.e. 
when loosing LAN connection.
I understand this is not a typical use case, still I expect TSVN to handle such 
situation and issue a proper error message, rather than crashing.]

If I'm reading the code correctly, the path variable is for some reason 
incorrect (it is not "absolute", with absolute is defined as starting with \\ 
or X:\ (X being a drive letter A-Z), with the \ translated to / internally in 
TSVN). I'm guessing that it is empty, since it doesn't make sense that 
undocking would just make it loose the \\ or drive letter. I'm not sure if this 
path is being supplied directly from TSVN or if it is constructed within 
Subversion code, and I'm not sure if some code could be added to check for an 
empty path when the network connection is lost.

However fast the network is reconnected there will always be a moment with no 
network. The part of the code that assert is the part that is reading the WC 
database on the network drive. In this case we are not even communicating with 
Subversion code on the other end but we are relying on Windows to provide us 
with access to the SQLite database file. So even if the code would not assert, 
you might end up with a situation where Windows is telling SQLite "sorry but 
that file is not available" (which in turn is telling Subversion something 
similar).

Conceivably there could be a "retry" logic that wait for a little while and 
retry every operation that could be interrupted but I think that will be a 
significant amount of work, and I'm not sure that will even be considered 
desirable.

All above being said, please also be aware of what TSVN and SQLite say about 
storing WCs on network shares:
* https://tortoisesvn.net/faq.html#wconshare
* https://www.sqlite.org/faq.html#q5

Kind regards,
Daniel Sahlberg

Re: What's the status of changing UUIDs of repos in working copies?

[Nico Kadel-Garcia]

On Thu, Jul 14, 2022 at 9:44 AM Daniel Shahaf  wrote:
>
> Ryan Schmidt wrote on Wed, 13 Jul 2022 21:45 +00:00:
> > [...] that way all your public users' working copies continue to work
> > as before, and you would just need to check out new working copies for
> > those hopefully fewer and more technically capable internal users who
> > were using the formerly private server with its old UUIDs.
>
> Or manually change the UUID in those working copies using sqlite3.

Or throw in the towel on trying to transform multiple simultaneous
upstream Subversion servers, and switch to git. Or switch to using a
git-svn setup to keep the upstream servers in sync