TortoiseSVN mailing list

[Stefan Kueng]

Hi,

Since the mailing list for the TortoiseSVN project hasn't been working 
for some time now, we've switched over to using Google groups instead.


So to discuss anything TSVN related, instead of using the old mailing 
list please go to:

https://tortoisesvn.net/community.html

or directly to https://groups.google.com/group/tortoisesvn


Stefan

--
   ___
  oo  // \\  "De Chelonian Mobile"
 (_,\/ \_/ \ TortoiseSVN
   \ \_/_\_/>The coolest interface to (Sub)version control
   /_/   \_\ http://tortoisesvn.net

Re: ASSERT

[Johan Corveleyn]

On Wed, Oct 11, 2017 at 8:51 AM, Mathias Feist
 wrote:
> 'D:\Development\SVN\Releases\TortoiseSVN-1.9.7\ext\subversion\subversion\libsvn_client\cleanup.c'
>
> line 227: assertion failed (svn_dirent_is_absolute(dir_abspath))
>
> Tried to update, error msg db file was missing. Followed advise to clean up,
> error msg db file was missing.

Hi Mathias,

Sorry for the late response, and thanks for reporting this. It's not
clear at the moment whether this is a bug in svn itself, or in
TortoiseSVN (by not correctly canonicalizing the input, before handing
it to the svn libraries).

Do you know if any strange input might be playing a role here? Is the
directory you're acting upon in some strange format, or ... ?
Also: what checkboxes did you have checked when running this 'cleanup'?
And another thought: if the working copy contains svn:externals
definitions, and you have the "include externals" checkbox checked,
maybe those externals are the culprit? Any strangely formatted
externals, or ...?

-- 
Johan

RE: GitHub svn bridge corrupting working copies

[Bert Huijben]

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: zondag 15 oktober 2017 21:28
> To: Ryan Schmidt 
> Cc: Subversion Users 
> Subject: Re: GitHub svn bridge corrupting working copies
> 
> Ryan Schmidt wrote on Sun, Oct 15, 2017 at 14:00:10 -0500:
> > On Oct 15, 2017, at 13:07, Daniel Shahaf wrote:
> > > Ryan Schmidt wrote on Sun, 15 Oct 2017 12:49 -0500:
> > >> And the problem will just occur again sometime later with a different
> node. The node it complains about is always a directory that someone else
> committed to recently, [...]
> > >
> > > Have you looked at these commits?  Is there anything unusual in them,
> > > e.g., do they involve renames?
> >
> > Nothing unusual; just modifying one file and adding another:
> >
> > https://github.com/macports/macports-
> ports/commit/2198debd25b02bcf7f6b17f79b415690449a85f0
> 
> Okay, so perhaps the problem has to do with revisions that add new
> files.
> 
> > Somehow I don't think specific revisions are the problem. I mean, I
> > can now check out a new working copy at revision 139307 and
> > successfully update it to 139308.  Meanwhile, on our server, once,
> > back in August, it encountered a corruption already halfway through
> > the process of checking out a new working copy. And on the next
> > checkout attempt it worked.
> 
> Indeed, there is little we can do without knowledge of the bridge.
> There is any number of ways in which these observations might be
> confounders.
> 
> > > You might be able to reproduce the problem by backdating your working
> > > copy, 'svn up -r N-1 && svn up -r N kde'.
> >
> > Inside the kde directory, I ran:
> ⋮
> > $ svn up -r 139308
> > Updating '.':
> > UU   kdepimlibs4/Portfile
> > Skipped 'kdepimlibs4/files/patch-do_not_include_cpp.diff' -- An
> obstructing working copy was found
> 
> That's interesting; why would there be an obstruction?
> 
> Maybe a file by this name already existed at some point, and was not
> removed cleanly?
> 
> Or perhaps github reported the 'add' to the client twice?

One probable cause for this would be that they somehow changed the revision 
number to hash mapping. I would hope they change the repository UUID in this 
case, but given how easy it is to change history in git, I wouldn't count on 
this.

Is this problem reproducible on a clean checkout from the same base revision?

Bert