[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: A concern about mergeinfo and compatability.

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Tue, 29 Jan 2008 19:44:14 -0800

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

This is an archived mail posted to the Subversion Dev mailing list.