Just ignore the file you don't need then?
Or try --disable-shared
Ian Sidor wrote on Thu, May 19, 2011 at 00:00:45 +0100:
> I'm building Subversion from source in order to generate static libraries to
> use in my own application.
>
> I can build Subversion fine but I don't seem to be getting an
I'm building Subversion from source in order to generate static libraries to
use in my own application.
I can build Subversion fine but I don't seem to be getting any libraries
(dylib's).
Here is what I type in terminal:
curl -O http://subversion.tigris.org/downloads/subversion-1.6.16.tar.gz
c
> Stefan Sperling :
> Steinar, I'm sorry we can't help quickly here. At the moment I have no time
> to look at this further. I hope you have a good backup you can restore from.
No luck there I'm afraid.
I have backups, but either they are too old to be of interest, or they
are corrupted as w
[snip]
> > http://mercurial.selenic.com/wiki/ConvertExtension
>
> I'm reading that page. It seems to support subversion->hg, not the
> reverse. it can convert "Mercurial" repositories to Mercurial
> repositories. hg to other formats is not mentioned.
That is correct. That page indicates that the
Hello,
I've an interesting case of repository corruption about which I've not
been able to find any information.
I've version 1.5.6 using FSFS stored on ext3 (RHEL 5.4). The repository
contains about 39k revisions. Revisions 0-36672 are fine and dump
without any problems. Revisions 36673-8 fail
On Wed, May 18, 2011 at 12:18:54PM +0200, Daniel Shahaf wrote:
> > There doesn't seem to be a duplicated block. The revision file itself seems
> > to be fine, expect that one of the lengths of the bad rev doesn't seem to
>
> Huh? Are you referring to the two 'length' attributes in the text: and
>
Stefan Sperling wrote on Wed, May 18, 2011 at 12:12:48 +0200:
> On Wed, May 18, 2011 at 10:53:13AM +0200, Daniel Shahaf wrote:
> > What came out of this thread? Is this one of the known corruption kinds?
>
> It doesn't seem to be known.
> It could be a flipped bits on the hard drive for all we kn
On Wed, May 18, 2011 at 10:53:13AM +0200, Daniel Shahaf wrote:
> What came out of this thread? Is this one of the known corruption kinds?
It doesn't seem to be known.
It could be a flipped bits on the hard drive for all we know.
> Is this is a case of a data block being written partially in one
Hi, Daniel,
> Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
>
> svn st -u
Thanks a lot. I must have been blind, as I did not find that one...
> Markus Schaber wrote on Wed, May 18, 2011 at 11:31:37 +0200:
> > Hello,
> >
> > Is there any command to verify whether the locks in the current
svn st -u
Markus Schaber wrote on Wed, May 18, 2011 at 11:31:37 +0200:
> Hello,
>
> Is there any command to verify whether the locks in the current working
> copy are still valid?
>
> A side question: Which ways are there for a lock go get invalid? I know
> the following:
> - Explicit lock break
Hello,
Is there any command to verify whether the locks in the current working
copy are still valid?
A side question: Which ways are there for a lock go get invalid? I know
the following:
- Explicit lock breaking / stealing.
- Copying the working copy directory tree, and then commit or release
th
[ CC += julianf ]
What came out of this thread? Is this one of the known corruption kinds?
Is this is a case of a data block being written partially in one place
and fully in another, or a case of a corrupt or truncated data block?
--
Daniel
(at hackathon room)
Steinar Bang wrote on Sat, May
Hi Stefan,
thanks for your feedback and I am sorry I have not responded sooner. But I
finally
found out what the problem seems to be, after your guidance.
Basically I had one file that had a mixture of different line ending styles, \r
followed
by another \r. This file had kanji characters in it,
Guten Tag Merrill, Shaun,
am Dienstag, 17. Mai 2011 um 19:01 schrieben Sie:
> however, the developer next to me can log into our server with his
> login on my machine and check in just fine.
[...]
>C:\SVN\trunk\ETL>svn commit . --username DOMAIN\userName --password Pwd123
> -m ""
Does the ot
14 matches
Mail list logo