On Thu, Jul 3, 2014 at 5:50 PM, Ben Reser wrote:
> On 7/3/14 2:16 PM, Stefan Sperling wrote:
> > Thanks for your report.
> >
> > This is definitely not intentional. I can reproduce this on 1.8.x but not
> > on trunk. Not sure yet when it was fixed on trunk.
>
> This was resolved by my commit in r
On Thu, Jul 3, 2014 at 6:24 PM, Daniel Shahaf
wrote:
> Mark Eichin wrote on Thu, Jul 03, 2014 at 14:59:30 -0400:
> > 1.6 on ubuntu precise gets this right, 1.8 on trusty gets it wrong, the
> > following repro script is from trusty:
> >
> > $ mkdir svnrmbug
> > $
1.6 on ubuntu precise gets this right, 1.8 on trusty gets it wrong, the
following repro script is from trusty:
$ mkdir svnrmbug
$ cd svnrmbug
/home/eichin/tmp/svnrmbug
$ svnadmin create repo
$ U=file://$(pwd)/repo
$ svn mkdir --parents -m 'base' $U/{trunk,branches,tags,branches/me,tags/me}
Commit
on, Aug 22, 2011 at 2:25 PM, Hyrum K Wright
wrote:
> That text is from the 1.5 section of the book. 1.5 is over 4 years
> old, so current behavior might be different...
>
> On Sun, Aug 21, 2011 at 8:48 PM, Mark Eichin wrote:
>> Huh. http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c
Huh. http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.copy.html
actually has a Note:
"You can only copy files within a single repository. Subversion does
not support cross-repository copying."
I guess that means that the bug is that it doesn't check uuids and
actually *enforce* this; I'm sure I'm
Ran across this while writing a "populate new repo" script, that used
svn cp to copy a set of svn-hooks in place (by definition from one
repo to another.) What happens is that when a file in the source repo
(called "foreign" here) has svn:executable set, the working dir in the
destination (called
oesn't get more attention... though as far as I can
tell, it works purely with a combination of the client command line
interface and rsync :-)
On Fri, May 13, 2011 at 5:21 PM, C. Michael Pilato wrote:
> On 05/13/2011 05:13 PM, C. Michael Pilato wrote:
>> On 05/12/2011 04:26 PM, Mar
cool, I'll admit I didn't take the time to look at existing test cases
to see what style to write them in (partly because I was mostly
simplifying the script I was using to perform the original goal);
looks like I didn't include trap "rm -rf" 0 lines either (but for
debugging the problem one proba
t;
$REPO2_DIR/hooks/pre-revprop-change
chmod +x $REPO2_DIR/hooks/pre-revprop-change
# 3:HEAD gives, falsely, "svnrdump: E205000: Unsupported revision
specifier used; use only integer values or 'HEAD'"
echo $REV = 4 $HEAD = 7
svnrdump dump --incremental -r $REV:$HEAD $REPO1 | svnrd
I'm working on some svn migration-with-history between repos from
different companies, git-svn isn't cutting it (close, but it loses
properties entirely, and doesn't really give me enough control) so I
thought I'd give svnrdump a try, given that it's been recommended for
this use a bunch of times..
10 matches
Mail list logo
