On Jan 29, 2008 8:22 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> But doing this for mergeinfo gives me pause, because I don't think that
> having 1.5 clients writing mergeinfo to the repository and then having that
> info being ignored by 1.4 clients is actually good. As 1.4 clients clone,
> tweak, and write node-revision information in the course of doing the whole
> version control thang, I think this will have the effect of disturbing the
> integrity of the data. As such, it seems we pretty much need to
Is this a realistic opportunity for corruption?
> And then, we have to deal with the upgrade path. Do we implement 'svnadmin
> upgrade', or do we require a dump and load?
I think 'svnadmin upgrade' is an awful idea. I think we'd be opening
a bigger can of worms then we'd be addressing "what do you mean this
doesn't do the 1.3->1.4 xdelta conversion?" So, if we go this route,
I'd be concerned that we'd then have to explain what it upgrades and
what it doesn't. Ugh.
I don't see a particular reason to be scared of dump/load - if you
choose to have lotsa repositories, you shouldn't be afraid of
dump/load. (Or, perhaps you'll realize the drawbacks of having
multiple repositories!)
If the admin doesn't want to be bothered by a dump/load, then we could
just disable merge tracking (iow, just report it as without merge
capability). Even if they set svn:mergeinfo, no biggie. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-30 04:44:25 CET