Hi Daniel,
Daniel Shahaf writes:
> Philip Martin wrote on Fri, Jul 23, 2010 at 12:03:01 +0100:
> > Like Stefan I don't understand why svnrdump is inventing revsion
> > properties. It should simply dump those that exist, it should not add
> > anything that does not exist.
> >
>
> +1. Folks can
Philip Martin wrote on Fri, Jul 23, 2010 at 12:03:01 +0100:
> Like Stefan I don't understand why svnrdump is inventing revsion
> properties. It should simply dump those that exist, it should not add
> anything that does not exist.
>
+1. Folks can use 'svnsync init --allow-non-empty' later (or
Hi Philip,
Philip Martin writes:
> They are all the same (REAL?), they are all just unversioned revision
> properties.
I probably misunderstood something somewhere- I'm making deductions
simply based on my limited observation. I've used the word "real" in
the context that those are the only prope
Ramkumar Ramachandra writes:
> Ramkumar Ramachandra writes:
>> svn:sync-from-url - it's clear why svnsync needs this. After the
>> `init`, subsequent calls to `sync` needs this information, but isn't
>> given it explicitly.
>
> We can keep this.
>
>> svn:sync-currently-copying and svn:sync-last-m
Hi again,
Ramkumar Ramachandra writes:
> svn:sync-from-url - it's clear why svnsync needs this. After the
> `init`, subsequent calls to `sync` needs this information, but isn't
> given it explicitly.
We can keep this.
> svn:sync-currently-copying and svn:sync-last-merged-rev - `sync` needs
> to
Hi Stefan,
Stefan Sperling writes:
> If these revision properties aren't set on the original repository,
> you should not include them in the dump.
>
> synsync creates these revision properties, but svnrdump should not.
>
> I think you should query the actual revprop values using the RA API
> (
6 matches
Mail list logo
