You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Chaya <ch...@gmail.com> on 2020/04/26 06:15:10 UTC
Re: commit failed due to "backwards-sliding source views" - what do
I do?
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
Re: commit failed due to "backwards-sliding source views" - what do
I do?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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
> > 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
>
>
>
Re: commit failed due to "backwards-sliding source views" - what do I do?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Apr 29, 2020 at 12:11 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Johan Corveleyn wrote on Wed, 29 Apr 2020 11:04 +0200:
> > On Wed, Apr 29, 2020 at 7:14 AM Chaya <ch...@gmail.com> wrote:
> > >
> > > 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))
> > >
> > > --
> > > Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html
> >
> > 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...
>
> 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 :-).
> 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
Re: commit failed due to "backwards-sliding source views" - what do
I do?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Wed, 29 Apr 2020 11:04 +0200:
> On Wed, Apr 29, 2020 at 7:14 AM Chaya <ch...@gmail.com> wrote:
> >
> > 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))
> >
> > --
> > Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html
>
> 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...
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
Re: commit failed due to "backwards-sliding source views" - what do I do?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Apr 29, 2020 at 7:14 AM Chaya <ch...@gmail.com> wrote:
>
> 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))
>
> --
> Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html
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
Re: commit failed due to "backwards-sliding source views" - what do
I do?
Posted by Chaya <ch...@gmail.com>.
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))
--
Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html
Re: commit failed due to "backwards-sliding source views" - what do
I do?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Tue, 28 Apr 2020 14:06 +0200:
> On Tue, Apr 28, 2020 at 8:16 AM Chaya <ch...@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
Re: commit failed due to "backwards-sliding source views" - what do I do?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Apr 28, 2020 at 8:16 AM Chaya <ch...@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!
>
> --
> Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html
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
Re: commit failed due to "backwards-sliding source views" - what do I do?
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Apr 30, 2020 at 1:23 AM Chaya <ch...@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
Re: commit failed due to "backwards-sliding source views" - what do
I do?
Posted by Chaya <ch...@gmail.com>.
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
--
Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html
Re: Lists history (was: Re: commit failed due to "backwards-sliding source views" - what do I do?)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
I pinged InfraAdmin offlist on the day he asked me to, told him where to
find the files (already prepared in the format mod_mbox expects
internally: gzipped mboxes in a particular naming pattern), and he
acknowledged. So from where I'm sitting, the ball is in Infra's court.
Nathan Hartman wrote on Wed, 15 Jul 2020 21:08 +00:00:
> Ping...
>
> On Fri, May 22, 2020 at 9:54 PM Greg Stein <gs...@gmail.com> wrote:
> >
> > Hey Daniel, et al,
> >
> > Sorry to leave this hanging. I've been thinking on the best approach, but I do not have answer just yet. My initial thinking is that we are going to decommission mail-*.apache.org, so any solution basically means: backfill on lists.a.o. That is going to require some coordination with our vendor. I'm tending towards "yes", but the path isn't clear yet.
> >
> > There is zero problem with placing the archives onto our mbox machine for long-term archival/safety, and is likely a first step regardless. Hit me up offlist, and we can figure that part out.
> >
> > Cheers,
> > Greg
> > InfraAdmin, ASF
> > (and old-school Subversion dude)
> >
> > On Sun, May 17, 2020 at 3:30 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >>
> >> Pinging VP Infra.
> >>
> >> Daniel Shahaf wrote on Mon, 11 May 2020 15:35 +0000:
> >> > Daniel Shahaf wrote on Wed, 29 Apr 2020 15:38 +0000:
> >> > > I've opened an INFRA ticket for importing the dev@ and users@ archives:
> >> > >
> >> > > https://issues.apache.org/jira/projects/INFRA/issues/INFRA-20213
> >> >
> >> > Infra declined to merge the pre-Apache archives into the main archives.
> >> > Instead they offered to host the pre-Apache archives on a service that's
> >> > accessible only to Apache Software Foundation members, and even then
> >> > available only on request. Infra also reminded us that we have the
> >> > option of appealing their decision to VP Infra, …
> >> >
> >> > … which I hereby do. David, the Subversion PMC requests that its
> >> > pre-Apache archives, about 240MB worth of gzipped mboxes, be publicly
> >> > served by the Apache Software Foundation. Please let the project
> >> > (Cc'd) know your answer.
> >> >
> >> > Cheers,
> >> >
> >> > Daniel
> >>
>
> Hi all,
>
> It is important that we preserve the early years (pre-Apache) of our
> mail archives, as that was the period of heaviest development and
> those mails document technical rationale for our implementation.
>
> Is there a path forward?
>
> Thanks,
> Nathan
>
Re: Lists history (was: Re: commit failed due to "backwards-sliding
source views" - what do I do?)
Posted by Nathan Hartman <ha...@gmail.com>.
Ping...
On Fri, May 22, 2020 at 9:54 PM Greg Stein <gs...@gmail.com> wrote:
>
> Hey Daniel, et al,
>
> Sorry to leave this hanging. I've been thinking on the best approach, but I do not have answer just yet. My initial thinking is that we are going to decommission mail-*.apache.org, so any solution basically means: backfill on lists.a.o. That is going to require some coordination with our vendor. I'm tending towards "yes", but the path isn't clear yet.
>
> There is zero problem with placing the archives onto our mbox machine for long-term archival/safety, and is likely a first step regardless. Hit me up offlist, and we can figure that part out.
>
> Cheers,
> Greg
> InfraAdmin, ASF
> (and old-school Subversion dude)
>
> On Sun, May 17, 2020 at 3:30 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>
>> Pinging VP Infra.
>>
>> Daniel Shahaf wrote on Mon, 11 May 2020 15:35 +0000:
>> > Daniel Shahaf wrote on Wed, 29 Apr 2020 15:38 +0000:
>> > > I've opened an INFRA ticket for importing the dev@ and users@ archives:
>> > >
>> > > https://issues.apache.org/jira/projects/INFRA/issues/INFRA-20213
>> >
>> > Infra declined to merge the pre-Apache archives into the main archives.
>> > Instead they offered to host the pre-Apache archives on a service that's
>> > accessible only to Apache Software Foundation members, and even then
>> > available only on request. Infra also reminded us that we have the
>> > option of appealing their decision to VP Infra, …
>> >
>> > … which I hereby do. David, the Subversion PMC requests that its
>> > pre-Apache archives, about 240MB worth of gzipped mboxes, be publicly
>> > served by the Apache Software Foundation. Please let the project
>> > (Cc'd) know your answer.
>> >
>> > Cheers,
>> >
>> > Daniel
>>
Hi all,
It is important that we preserve the early years (pre-Apache) of our
mail archives, as that was the period of heaviest development and
those mails document technical rationale for our implementation.
Is there a path forward?
Thanks,
Nathan
Re: Lists history (was: Re: commit failed due to "backwards-sliding
source views" - what do I do?)
Posted by Greg Stein <gs...@gmail.com>.
Hey Daniel, et al,
Sorry to leave this hanging. I've been thinking on the best approach, but I
do not have answer just yet. My initial thinking is that we are going to
decommission mail-*.apache.org, so any solution basically means: backfill
on lists.a.o. That is going to require some coordination with our vendor.
I'm tending towards "yes", but the path isn't clear yet.
There is zero problem with placing the archives onto our mbox machine for
long-term archival/safety, and is likely a first step regardless. Hit me up
offlist, and we can figure that part out.
Cheers,
Greg
InfraAdmin, ASF
(and old-school Subversion dude)
On Sun, May 17, 2020 at 3:30 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> Pinging VP Infra.
>
> Daniel Shahaf wrote on Mon, 11 May 2020 15:35 +0000:
> > Daniel Shahaf wrote on Wed, 29 Apr 2020 15:38 +0000:
> > > I've opened an INFRA ticket for importing the dev@ and users@
> archives:
> > >
> > > https://issues.apache.org/jira/projects/INFRA/issues/INFRA-20213
> >
> > Infra declined to merge the pre-Apache archives into the main archives.
> > Instead they offered to host the pre-Apache archives on a service that's
> > accessible only to Apache Software Foundation members, and even then
> > available only on request. Infra also reminded us that we have the
> > option of appealing their decision to VP Infra, …
> >
> > … which I hereby do. David, the Subversion PMC requests that its
> > pre-Apache archives, about 240MB worth of gzipped mboxes, be publicly
> > served by the Apache Software Foundation. Please let the project
> > (Cc'd) know your answer.
> >
> > Cheers,
> >
> > Daniel
>
>
Re: Lists history (was: Re: commit failed due to "backwards-sliding
source views" - what do I do?)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Pinging VP Infra.
Daniel Shahaf wrote on Mon, 11 May 2020 15:35 +0000:
> Daniel Shahaf wrote on Wed, 29 Apr 2020 15:38 +0000:
> > I've opened an INFRA ticket for importing the dev@ and users@ archives:
> >
> > https://issues.apache.org/jira/projects/INFRA/issues/INFRA-20213
>
> Infra declined to merge the pre-Apache archives into the main archives.
> Instead they offered to host the pre-Apache archives on a service that's
> accessible only to Apache Software Foundation members, and even then
> available only on request. Infra also reminded us that we have the
> option of appealing their decision to VP Infra, …
>
> … which I hereby do. David, the Subversion PMC requests that its
> pre-Apache archives, about 240MB worth of gzipped mboxes, be publicly
> served by the Apache Software Foundation. Please let the project
> (Cc'd) know your answer.
>
> Cheers,
>
> Daniel
Re: Lists history (was: Re: commit failed due to "backwards-sliding
source views" - what do I do?)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Wed, 29 Apr 2020 15:38 +0000:
> I've opened an INFRA ticket for importing the dev@ and users@ archives:
>
> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-20213
Infra declined to merge the pre-Apache archives into the main archives.
Instead they offered to host the pre-Apache archives on a service that's
accessible only to Apache Software Foundation members, and even then
available only on request. Infra also reminded us that we have the
option of appealing their decision to VP Infra, …
… which I hereby do. David, the Subversion PMC requests that its
pre-Apache archives, about 240MB worth of gzipped mboxes, be publicly
served by the Apache Software Foundation. Please let the project
(Cc'd) know your answer.
Cheers,
Daniel
Re: Lists history (was: Re: commit failed due to "backwards-sliding
source views" - what do I do?)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Wed, 29 Apr 2020 10:02 -0400:
> On Tue, Apr 28, 2020 at 1:17 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > 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.]
>
> +1, if it can be done, and there isn't some glaring reason not to
> (such as legal), then I'm in favor of that.
For starters, I've grabbed a copy from haxx.se and mirrored it to
svn-qavm.apache.org and home.apache.org.¹
I've opened an INFRA ticket for importing the dev@ and users@ archives:
https://issues.apache.org/jira/projects/INFRA/issues/INFRA-20213
Questions for us:
- TODO: Double check that there are no messages to
*@subversion.tigris.org in https://svn.haxx.se/dev/ and
https://svn.haxx.se/users/ in or after January 2011.
- TODO: The archives for 200911, 200912, and possibly a few subsequent
months contain messages to both the @s.t.o and @s.a.o mailing lists,
so there's a question of deduplication (how to remove @s.a.o messages
from the svn.haxx.se dataset before importing it).
- Do we want to import the https://svn.haxx.se/org/ archives as well?
- Do we want to import the archives of svn-full-committers@? (I guess
not?)
- And #svn-dev (the colabti.org channel logs)?
The archives of svnsecurity@ and security@s.t.o are already in the PMC
repository, and I believe they are complete. (I checked that the last
message in the mbox file in /repos/private and the last message in my
personal email archives match, and they do, modulo spam received
afterwards.)
Cheers,
Daniel
¹ If anyone wants to get a copy, you can get it via:
.
% sftp home.apache.org
sftp> cd /home/danielsh/svn-haxx-se-mirror/
sftp> get …
.
If you have access to svn-qavm.a.o you can alternatively do:
.
rsync -avP svn-qavm.apache.org:/srv/svn-haxx-se-mirror ./
Re: Lists history (was: Re: commit failed due to "backwards-sliding
source views" - what do I do?)
Posted by Nathan Hartman <ha...@gmail.com>.
[Moving from users@ to dev@...]
On Tue, Apr 28, 2020 at 1:17 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> 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-committers@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.
Until I looked more closely, I guess I had assumed that all of the
pre-migration data (including list archives) were brought over in the
move to ASF. Looks like some stuff was left behind.
The earliest emails, during the period of heaviest development, must
contain all sorts of gems of knowledge and design rationale that
aren't available elsewhere. So...
> 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.]
+1, if it can be done, and there isn't some glaring reason not to
(such as legal), then I'm in favor of that.
Nathan
Lists history (was: Re: commit failed due to "backwards-sliding
source views" - what do I do?)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Tue, 28 Apr 2020 10:09 -0400:
> On Tue, Apr 28, 2020 at 2:16 AM Chaya <ch...@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-committers@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
Re: commit failed due to "backwards-sliding source views" - what do I do?
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Apr 29, 2020 at 1:14 AM Chaya <ch...@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
Re: commit failed due to "backwards-sliding source views" - what do
I do?
Posted by Chaya <ch...@gmail.com>.
Hi,
I am using the latest versions of svn and git. And what do you mean by
"history-rewriting gymnastics" ? Could you please explain?
--
Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html
Re: commit failed due to "backwards-sliding source views" - what do I do?
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Apr 28, 2020 at 2:16 AM Chaya <ch...@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