FWIW svnmerge works the way I expected svn merge tracking would work.
svn merge tracking doesn't.
So I'm still using svnmerge...
But one of these days I'll figure out if it is possible to to use
built-in merge tracking to my usecase. I've versioned my home
directory, and where I end up with a fi
Platform:
debian 6.0.1 "squeeze",
subversion 1.6.16dfsg-1+b1,
fsfsverify.py from
http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side
python 2.6.6-3+squeeze6
(information about the repository at the end of this mesage)
Yesterday I discovered that my subversion repository
> Stefan Sperling :
> The script probably took a wrong guess.
> Hopefully this is the known corruption problem with a duplicate block of
> data in the revision file.
> Can you check if the original revision file (i.e. not modified by
> fsfsverify.py) somewhere contains a data block which con
>>>>> Steinar Bang :
>>>>> Stefan Sperling :
>> Try to locate boundaries of representations, which look as follows:
>> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
>>A representation begins with a line c
> Daniel Shahaf :
> No, you should be looking for the sequence of bytes starting at offset
> 1916. So, the bytes are:
> 53564e018c0c823d
> (for example, 'xxd -s 1916 -l 10 -ps' will tell you that)
Um... how do one determine the length of the sequence? You are using 10
bytes I guess...
>>>>> Steinar Bang :
> Um... how do one determine the length of the sequence? You are using
> 10 bytes I guess...?
Never mind. It's from that structure description you posted.
I'll study that some more.
>>>>> Steinar Bang :
>>>>> Steinar Bang :
>> Um... how do one determine the length of the sequence? You are using
>> 10 bytes I guess...?
> Never mind. It's from that structure description you posted.
Er sorry! Not you, but Stefan Sperling. I didn't look at the From
headers of the emails.
>>>>> Steinar Bang :
>>>>> Steinar Bang :
>>>>> Stefan Sperling :
>>> Try to locate boundaries of representations, which look as follows:
>>> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
>
> 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
>>>>> Steinar Bang :
> I've been looking to see if there are any tools that can slurp out the
> history of a repository, using the svn client API. But all repository
> conversion seems to be based on "svnadmin dump". And "svnadmin dump"
> c
>>>>> Daniel Shahaf :
> Steinar Bang wrote on Sat, May 21, 2011 at 18:26:30 +0200:
[snip! svnsync and svnrdump]
>> .., it would have been nice if it was possible to tell these tools to
>> make a clone of a particular part of the repository into a new
>> repos
>>>>> Steinar Bang :
> I tried adding this to /svn/conf/authz:
> [/trunk/someprog]
> * =
> (everything else in the file are comments)
> But both tools still break at revision 683, which is in the path
> /trunk/someprog/metamodeller.
[snip!]
> I was using t
>>>>> Steinar Bang :
>>>>> Steinar Bang :
>> I tried adding this to /svn/conf/authz:
>> [/trunk/someprog]
>> * =
>> (everything else in the file are comments)
[snip!]
> So I uncommented this line in the sample svnserve.conf:
> # auth
I have my unix/linux home directory checked into subversion. I would
like to restrict the file mode on some of these files to -rw---
Can subversion support this?
I've googled and found mention of svn:unix-mode, which may be what I'm
looking for, eg. this:
http://thread.gmane.org/gma
> Tyler Roscoe :
> Subversion doesn't track file permissions in this way.
Yes, looking closer at the thread I found, it is a patch that was shot
down in February 2005
http://svn.haxx.se/dev/archive-2005-02/index.shtml#5
> The files in your woking copy will have permissions based on t
15 matches
Mail list logo
