Re: commit failed due to "backwards-sliding source views" - what do I do?

[svnswapnil]

Do we have any solution on this problem, I am also facing this issue
intermittently "svn diff has backwards sliding source views commit error
from slave repository", Is it really associated with some antivirus, then
exactly what needs to be done to address it.

Currently only work-around which has worked for me is, relocate the working
copy to master URL and do the check-in.
SVN version Used are: 1.7.8 ( server & tortoise svn client )
I wan't to avoid this issue going forward, any steps to solve this problem
would be great help, thanks!

Regs,
Swapnil



--
View this message in context: http://subversion.1072662.n5.nabble.com/commit-failed-due-to-backwards-sliding-source-views-what-do-I-do-tp104150p190425.html
Sent from the Subversion Users mailing list archive at Nabble.com.

[Chaya]

Has anyone found solution to this problem?
I am getting this error while running git svn fetch command.
Tried many things to solve this issue, but no luck.
If anyone has found solution , it would be very helpful if you post it here.
Thanks!



--
Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html

[Johan Corveleyn]

I did not find much about this error. Just this SO question, without a
real answer:
https://stackoverflow.com/questions/24904329/git-svn-clone-failed-due-to-svndiff-backward-sliding-source-view

Seems to me the problem is specific to git-svn, so I'm thinking you
should contact people in the git-svn community. They might know more
or have experience with this kind of problem.

--
Johan

[Nathan Hartman]

On Tue, Apr 28, 2020 at 2:16 AM Chaya <chaya...@gmail.com> wrote:
>
> Has anyone found solution to this problem?
> I am getting this error while running git svn fetch command.
> Tried many things to solve this issue, but no luck.
> If anyone has found solution , it would be very helpful if you post it here.
> Thanks!

A search through the mailing list archive at
https://svn.haxx.se/users/ (the lists.apache.org archive doesn't seem
to go farther back than 2009?) shows some hits for backwards-sliding
windows and such, but all the ones I've found are very old posts from
2006 and 2008. Perhaps the "best" one I found was this report from
2006 that the OP later reported was caused by some antivirus software:

https://svn.haxx.se/users/archive-2006-08/0398.shtml

My best guesses would be to make sure you're using recent versions of
svn and git, check whether this error is due to any history-rewriting
gymnastics on the git side of things, and if all else fails, look into
whether antivirus or some other software is playing a role here.

Nathan

[Daniel Shahaf]

Nathan Hartman wrote on Tue, 28 Apr 2020 10:09 -0400:
> On Tue, Apr 28, 2020 at 2:16 AM Chaya <chaya...@gmail.com> wrote:
> >
> > Has anyone found solution to this problem?
> > I am getting this error while running git svn fetch command.
> > Tried many things to solve this issue, but no luck.
> > If anyone has found solution , it would be very helpful if you post it here.
> > Thanks!
>
> A search through the mailing list archive at
> https://svn.haxx.se/users/ (the lists.apache.org archive doesn't seem
> to go farther back than 2009?)

Subversion moved to Apache in 2009. Neither lists.a.o nor
mail-archives.a.o would be expected to go farther back than that.

Before the migration, the lists were @subversion.tigris.org (except
private@, which was svn-full-...@red-bean.com), and instead of
being part of ASF we had our own Subversion Corporation
(see https://svn.haxx.se/org/, and the archive.org snapshots of
subversion.org). The tigris lists used to be independently archived in
several places, but at least two of them (tigris and gmane) have closed
since then.

It wouldn't be a bad idea to download haxx.se's archives to Apache
hardware so we have an independent backup. In fact, Infra might even
be willing to inject the pre-migration data into the
mail-archives.a.o/lists.a.o archives, so we have unified archives.

[When we migrated legal@ allowed us to add the historical release
tarballs to archive.a.o/dist/ even though they contained LGPL
dependency tarballs (which aren't normally allowed in Apache
releases). In light of this, I can't imagine backfilling the lists
would be a problem.]

The first step, though, would be to get the raw mbox's from haxx.se.
The owner of that domain is a full committer, so it should be easy…

Cheers,

Daniel

[Daniel Shahaf]

Johan Corveleyn wrote on Tue, 28 Apr 2020 14:06 +0200:
> On Tue, Apr 28, 2020 at 8:16 AM Chaya <chaya...@gmail.com> wrote:
> >
> > Has anyone found solution to this problem?
> > I am getting this error while running git svn fetch command.

Is it a public repository, so we can try to reproduce the error ourselves?

What's the URL scheme (http(s) or svn(+ssh))?

Version numbers of svn on the server and client and git on the client?

> > Tried many things to solve this issue, but no luck.
> > If anyone has found solution , it would be very helpful if you post it here.
> > Thanks!
>

> I did not find much about this error. Just this SO question, without a
> real answer:
> https://stackoverflow.com/questions/24904329/git-svn-clone-failed-due-to-svndiff-backward-sliding-source-view
>
> Seems to me the problem is specific to git-svn, so I'm thinking you
> should contact people in the git-svn community. They might know more
> or have experience with this kind of problem.

If the git-svn maintainers have questions or bug reports for us, we'd
be happy to engage with them.

Cheers,

Daniel

[Chaya]

Hi,
I am using the latest versions of svn and git. And what do you mean by
"history-rewriting gymnastics" ? Could you please explain?

[Chaya]

1. Unfortunately, it's not a public repository.
2. The SVN project repo is actually file based. So I had to convert it to
svn protocol before cloning to git.
3. Using latest version of svn (version 1.13.0 (r1867053)) and git ( version
1.13.0 (r1867053))

[Nathan Hartman]

On Wed, Apr 29, 2020 at 1:14 AM Chaya <chaya...@gmail.com> wrote:

Hi,
I am using the latest versions of svn and git. And what do you mean by
"history-rewriting gymnastics" ? Could you please explain?

Hi,

I don't use the git-svn bridge myself, but I have read about it (admittedly, quite some time ago). I remember there were suggestions to keep the git history linear so that it will match the way Subversion works, and recommendations of things not to do in git because they could prevent the bidirectional bridge from working properly. I don't remember the details; I wrote "history-rewriting gymnastics" in a hurry.

Nathan 

[Johan Corveleyn]

You're using "git svn", which is part of git (sorry, I thought git-svn
was a separate project, but it seems to be simply part of git itself
now, as a subcommand):
https://git-scm.com/docs/git-svn

From what I understand 2.26.2 is the latest release of git currently
(see https://git-scm.com/).

IMHO you'll need to ask the git community for support on the "git svn"
command. I have no idea what kind of svn-like operations the "git svn"
tool really performs under the hood. Maybe there are certain
pre-conditions you need to make sure of, before running "git svn" on a
repository (those should be documented at
https://git-scm.com/docs/git-svn, or if not you should ask the git
community).

Maybe one more suggestion: you say in (2) that you "had to convert it
to svn protocol before cloning to git". What do you mean with "convert
it to svn protocol"? Did you first use it as a file-based repository
(in SVN with a file:// URL), and before using "git svn" you had to set
up and "svnserve" process to serve it? Perhaps the (file-based)
repository you started from is in a very old format which isn't
supported well by "git svn". In that case, perhaps you should first
try to "svnadmin upgrade $REPO" with your svn tools, before trying to
run "git svn" on it. It's worth a try...

HTH,
--
Johan

[Daniel Shahaf]

Johan, what do you mean by 'a very old format which isn't supported well
by "git svn"'? How would you tell, over the svn:// protocol, whether
a repository is of a 'very old format'? I'd expect the server to hide
these details from the client — assuming the version of svnserve is new
enough, at least. [Well, one thing the server won't hide is the
"mergeinfo" capability, which depends on the backend format number, but
that's probably not related to the case at hand.]

In any case, Chaya, could you run `svnserve --version -q` and `svnadmin
info /path/to/repos` and post the output here? In addition to Johan's
direction, there's a svn_txdelta_parse_svndiff() call in BDB that I'd
like to rule out. In fact, I wish I had a backtrace of the error (it's
generated by us: see subversion/libsvn_delta/svndiff.c:write_handler),
but I don't even know whether to ask you to debug svnserve(8) on the
server or svn(1) or git-svn(1) on the client… as Johan said, we really
need the git-svn folks to look into this first and come back to us with
a reproduction recipe in terms of our APIs.

Also, could you try creating an svnsync mirror of the repository, and
let us know whether that succeeded or errored?

Cheers,

Daniel

[Johan Corveleyn]

For instance an svn repository that was created by svnadmin 1.0, with
BDB backend. Or a pretty old version of FSFS or something like that.

> How would you tell, over the svn:// protocol, whether
> a repository is of a 'very old format'? I'd expect the server to hide
> these details from the client — assuming the version of svnserve is new
> enough, at least. [Well, one thing the server won't hide is the
> "mergeinfo" capability, which depends on the backend format number, but
> that's probably not related to the case at hand.]

I assumed, because Chaya said the "SVN project repo is actually file
based", that she would have control over it as an admin, and perhaps
would know more about its history and / or exact version, setup, etc.
But maybe I was a bit too terse there, so thanks for chiming in and
adding some concrete commands which could give us some more
information :-).

> In any case, Chaya, could you run `svnserve --version -q` and `svnadmin
> info /path/to/repos` and post the output here? In addition to Johan's
> direction, there's a svn_txdelta_parse_svndiff() call in BDB that I'd
> like to rule out. In fact, I wish I had a backtrace of the error (it's
> generated by us: see subversion/libsvn_delta/svndiff.c:write_handler),
> but I don't even know whether to ask you to debug svnserve(8) on the
> server or svn(1) or git-svn(1) on the client… as Johan said, we really
> need the git-svn folks to look into this first and come back to us with
> a reproduction recipe in terms of our APIs.
>
> Also, could you try creating an svnsync mirror of the repository, and
> let us know whether that succeeded or errored?
>
> Cheers,
>
> Daniel

--
Johan

[Daniel Shahaf]

Johan Corveleyn wrote on Wed, 29 Apr 2020 12:23 +0200:
> On Wed, Apr 29, 2020 at 12:11 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote:
> > Johan, what do you mean by 'a very old format which isn't supported well
> > by "git svn"'?
>
> For instance an svn repository that was created by svnadmin 1.0, with
> BDB backend. Or a pretty old version of FSFS or something like that.
>
> > How would you tell, over the svn:// protocol, whether
> > a repository is of a 'very old format'? I'd expect the server to hide
> > these details from the client — assuming the version of svnserve is new
> > enough, at least. [Well, one thing the server won't hide is the
> > "mergeinfo" capability, which depends on the backend format number, but
> > that's probably not related to the case at hand.]
>
> I assumed, because Chaya said the "SVN project repo is actually file
> based", that she would have control over it as an admin, and perhaps
> would know more about its history and / or exact version, setup, etc.
> But maybe I was a bit too terse there, so thanks for chiming in and
> adding some concrete commands which could give us some more
> information :-).

I don't think you were too terse; I just didn't understand what failure
mode your recommendation to upgrade the repository was meant to rule out.

In the meantime I've managed to eyeball all callsites of the error
message in the subject on our end, and I see three scenarios (for the
specific case of git-svn over svn://):

- if the repository uses the BDB backend (+ other conditions that I haven't determined)

- during a 'commit' operation

- during a 'blame' operation (on a 1.1.0 (sic) or newer server)

Given this, the advice given upthread applies.

Cheers,

Daniel

[Chaya]

Hi all,

Thanks for all the suggestions and hints given.

The problem is finally solved.
Here is my analysis:
I copied the SVN repository to my local machine (which was on network drive
before).
The 'git svn clone' command does not work for file based repository. And
this is why I had to convert the repo to svn protocol as I mentioned before.
So now, I again converted the local repository link to svn protocol and
tried git svn clone again. But unfortunately, it again failed at the same
point.
So, instead of git-svn , I used subgit (https://subgit.com/documentation/).
Subgit allows to use file based repository and also conversion happens
aggressively. Using subgit , I was able to migrate successfully.
Still have no clue why I get this "svndiff has backwards-sliding source
views" error while performing git svn clone on svn protocol.

Regards,
Chaya

[Nathan Hartman]

On Thu, Apr 30, 2020 at 1:23 AM Chaya <chaya...@gmail.com> wrote:

Hi all,

Thanks for all the suggestions and hints given.

The problem is finally solved.
Here is my analysis:
I copied the SVN repository to my local machine (which was on network drive
before).
The 'git svn clone' command does not work for file based repository. And
this is why I had to convert the repo to svn protocol as I mentioned before.
So now, I again converted the local repository link to svn protocol and
tried git svn clone again. But unfortunately, it again failed at the same
point.
So, instead of git-svn , I used subgit (https://subgit.com/documentation/).
Subgit allows to use file based repository and also conversion happens
aggressively. Using subgit , I was able to migrate successfully.
Still have no clue why I get this "svndiff has backwards-sliding source
views" error while performing git svn clone on svn protocol.

Glad you were able to solve this.

Thank you for letting us know, and for explaining your solution to help others who might have the same question in the future.

Best regards,

Nathan