On Tue, Jan 1, 2013 at 2:41 AM, Ben Reser <ben_at_reser.org> wrote:
> On Mon, Dec 31, 2012 at 4:47 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
>> (This is currently not possible because svnsync assumes that it writes
>> to the repository root and assumes revnums in the src and dest
>> repositories must equal; with the change, what will have to be equal is
>> some sort of svn:sync-source-revision revprop on file://$PWD/r/llvm)
>> (BTW, an obvious improvement would be to mirror only a part of the llvm
>> history --- either temporally (only N recent revisions), spatially (only
>> some subtrees), or both.)
> I've actually looked at adjusting svnsync to handle this but I just
> haven't gotten back to actually doing the work. So many things to do
> so little time. :D
> This might be a stop gap way of handling this but the better solution
> long term is what Branko was talking about with being able to svn cp
> between repos and then handle the merges.
> If both things are equal time or the cp/merge between repos is only
> slightly more time I'd say we shouldn't bother with the svnsync
> solution since in my opinion it pollutes the svnsync tool.
A more flexible svnsync might still be interesting, because it makes
you less dependent on the source repo. If that source repo vanishes,
you still have the complete history of the part you synced (for
instance, with the foreign cp approach, maybe 'svn log' will want to
follow the history accross the copy boundary -- so it needs to be able
to handle connectivity problems to the source repo, and if the source
repo vanishes you can't see those log entries anymore ever).
I guess it depends on the use case. With the "flexible svnsync" you're
actually doing exactly that ... an svnsync, so you have a full
independent copy of the part you wanted. With the "remote cp" your
repo remains coupled with the source repo.
Received on 2013-01-01 19:54:38 CET