Hi list,
we have a quite old & grown svn repository here. With some "interesting"
svn:mergeinfo Properties. (see the diff below)
This seems to be been allowed in earlier svn versions.
For backup Issues svn copy worked fine for all the time,
but now we want to update our server (svn version & hard
Jan Stürtz writes:
> Hi list,
> we have a quite old & grown svn repository here. With some "interesting"
> svn:mergeinfo Properties. (see the diff below)
>
> This seems to be been allowed in earlier svn versions.
>
> For backup Issues svn copy worked fine for all the time,
> but now we want to up
On Fri, Aug 16, 2013 at 10:51:58AM +0100, Philip Martin wrote:
> The mergeinfo is only parsed for partial dumps, i.e. when the start
> revision greater than one, as this allows the dump process to issue a
> warning when the mergeinfo refers to revisions not in the dump file.
> The only workaround i
Hi all,
a short test with the latest release of server, version 1.8.1 (r1503906)
compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows gives the same results.
Best regards,
Mark
i.A. Mark Piontek
Fabrikautomation - Entwicklungsingenieur Identifikationssysteme
Pepperl+Fuchs GmbH
Lilientha
Get your legacy material off BDB and onto FSFS, ASAP. At least make sure
you have *good* backups and are prepared to lose all that data if you
don't. BDB has been, in my experience with much older versions of
Subversion and with years of Linux application experience, prone to data
corruption from u
[ Sidenote: this list prefers bottom-posting (putting your reply at
the bottom) or in-line replying. Also, try to avoid the legal
boilerplate -- this is a public, archived mailinglist, so it doesn't
make much sense. I've rearranged your reply accordingly. More below
... ]
> -Ursprüngliche Nach
Note that it is sometimes much, much faster and creates much smaller and
cleaner repositories, to simply "svn export" and "svn import" the data
files themselves to a new repository. You don't get the history, but a
pointer to the old repository kept online in read only mode may be
considered enou
I just checked with 1.7 client, it shows the same behaviour.
Best regards,
Mark
i.A. Mark Piontek
Fabrikautomation - Entwicklungsingenieur Identifikationssysteme
Pepperl+Fuchs GmbH
Lilienthalstraße 200
68307 Mannheim
Telefon: +49 621 776-1358
Telefax: +49 621 776-1890
E-Mail: mpion...@de.pepperl
While upgrading from 1.6 to 1.8, I noticed that make install failed
to copy mod_authz_svn.so/mod_dav_svn.so to /path/to/apache/modules
per the INSTALL which resulted in these errors on seemingly random
commits:
Delta source ended unexpectedly [500, #23]
could not write the file contents [500,
Good Morning
You have a preview release of this fix, or if it will be developed?
thank you
Att
John D Groenveld writes:
> I don't see a rule in the Makefile to apxs -i or otherwise copy
> those DSOs though they are correctly built and configure correctly
> sets INSTALL_APACHE_MODS = true in the Makefile
The rule for installing apache modules is in build-outputs.mk:
install-mods-shared: s
In message <87ioz5iypv@ntlworld.com>, Philip Martin writes:
>install-mods-shared: subversion/mod_dav_svn/mod_dav_svn.la subversion/mod_auth
>z_svn/mod_authz_svn.la
>if $(INSTALL_APACHE_MODS) ; then cd subversion/mod_dav_svn ; $(MKDIR)
>"$(APACHE_LIBEXECDIR)" ; $(INSTALL_MOD_SHARED) -n
John D Groenveld writes:
> In message <87ioz5iypv@ntlworld.com>, Philip Martin writes:
>>install-mods-shared: subversion/mod_dav_svn/mod_dav_svn.la subversion/mod_auth
>>z_svn/mod_authz_svn.la
>>if $(INSTALL_APACHE_MODS) ; then cd subversion/mod_dav_svn ; $(MKDIR)
>>"$(APACHE_LIBEXEC
> >
> > If a project doesn't want to accept a change, they "fork" to a new
> > "history". The tool does this with a svn cp
> > and an update to the svn:externals property. They
now
> > lose sight of what the other project commits after that fork though.
The
> > backend of where the file is sto
On Fri, Aug 16, 2013 at 11:14 AM, wrote:
>>>
>> In subversion's view a copy is a branch so any distinction is strictly
>> your own convention. Likewise for tags, except that there is a
>> generally accepted convention of not committing changes after a tag
>> copy. Do you have additional conven
I have inherited a REALLY old SVN server that was mismanaged for years.
They were using WebDAV successfully for so long they never noticed any
issues under the hood, but the BDB is corrupt and cannot run an svnadmin
dump on it to move it to a new server that I built that has all the latest
SVN bits
On 16 Aug 2013 14:46, "Angelo Tavares" wrote:
>
> Good Morning
>
> You have a preview release of this fix, or if it will be developed?
>
Please save the mailing list readers some time by at least providing the
description and preferably also a link to the issue.
Thanks
--
Johan
Good Morning
You have a preview release of this fix, or if it will be developed?
http://subversion.tigris.org/issues/show_bug.cgi?id=4039
Att
I have installed subclipes on eclipse (kepler).
Subclipse is installed.
I can connect to a repository on a remote server via http(s).
Checkin out the repository is no problem.
Then I add a directory and want to commit this change.
After 3 time giving user/password this is the result:
---
On Fri, Aug 16, 2013 at 2:32 PM, Harry van Rijn
wrote:
> I have installed subclipes on eclipse (kepler).
> Subclipse is installed.
>
> I can connect to a repository on a remote server via http(s).
> Checkin out the repository is no problem.
> Then I add a directory and want to commit this change.
We have an old SVN database corruption we need help with. (SVN 1.1 with BDB
4.2)
Does anyone know of someone who consults on this sort of thing?
--
Regards,
Dana Epp
Dana,
This page of the subversion book sounds like it might be helpful in your
situation:
http://subversion.apache.org/faq.html#wedged-repos
I am sure that switching to a FSFS repository data store with your new
system is advisable.
chris
On Fri, Aug 16, 2013 at 1:37 PM, Dana Epp wrote:
> I
Hello-
We have a custom tunnel protocol withrepository URLs of the form:
svn+foo_bar://
After upgrading from svn 1.7.x to 1.8.1, these URLs are considered
invalid, giving an error of:
svn: E17: Illegal repository URL
This occurs on an
Excuse me, I will send my reply to the list.
Andy Levy schreef op 2013-08-16 21:54:
Don't tell just me, reply to all & keep it on the list.
On Fri, Aug 16, 2013 at 3:47 PM, Harry van Rijn
wrote:
Andy Levy schreef op 2013-08-16 20:41:
On Fri, Aug 16, 2013 at 2:32 PM, Harry van Rijn
wrote:
I
On 16.08.2013 23:10, Eric Hall wrote:
> Hello-
> We have a custom tunnel protocol withrepository URLs of the form:
>
> svn+foo_bar://
>
> After upgrading from svn 1.7.x to 1.8.1, these URLs are considered
> invalid, giving an error of:
>
> svn: E17: Illeg
Ya, I will definitely load the repo into fsfs on the new system.
I tried the recovery to no avail yesterday.
I just completed a restore of the VM to a state before all this started and
here is what I now see.
Trying to run an svnadmin dump gives me:
svn: bdb: Program version 4.2 doesn't match e
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: vrijdag 16 augustus 2013 23:29
> To: users@subversion.apache.org
> Subject: Re: svn 1.8.1 fails on underscore in the tunnel protocol
>
> On 16.08.2013 23:10, Eric Hall wrote:
> > Hello-
> > We have a custom
If all commits were through that mod_dav_svn, you should get an svnadmin
that is linked to the same BDB as that mod_dav_svn.
It is not unlikely that there is somewhere a second install of Subversion on
you machine. (Maybe in some home directory?). Trying to locate that one
might be easier than
Ya, that was what I meant. 4.4. I imagine if svnadmin is at 4.4, this
should all work. I took a snapshot of the VM and am now walking through
upgrades until I find a subversion package with libdb4.4. The guys at
snapshot.debian.org are my hero... without that side I would be dead in the
water.
Fin
Well, we are making some progress. All binaries are linked to libdb-4.4. I
ended up having to move subversion to v1.4 for this.
When I try a dump I now get:
svnadmin: Berkeley DB error for filesystem '/var/svn/db' while committing
Berkeley DB transaction:
DB_RUNRECOVERY: Fatal error, run database
Well, I think I got it. Thanks to everyone who was able to provide the
input both here on the list and in the #svn IRC channel .
As a final summary of what was happening ends up that the libdb4.4 I
had on the system had a bug that broke subversion back in 2007. So
upgrading everything to 4.4 e
31 matches
Mail list logo
