I don't normally post to the dev list, but I wanted to respond to your
above comment. See response below...
On Jan 30, 2008, at 11:42 AM, Mark Phippard wrote:
> On Jan 29, 2008 10:44 PM, Justin Erenkrantz <justin_at_erenkrantz.com>
> wrote:
>> 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
>
> The more I think about requiring a dump/load the more I hate it. I
... snip
>
> We still need to bump the format for the mergeinfo node changes. We
> could do this with an svnadmin upgrade or other utility that made the
> necessary changes, but could run quickly. Personally, I would still
> be in favor of doing this automatically and catering to the bulk of
> our user base. I know this would cause problems for groups that share
> a repository via file:// but that is still a tiny fraction of our
> users. If a 1.5 client bumps the format, it shuts out the 1.4
> clients. So at least there is not any corruption that will happen.
Are you suggesting that the repository format would be auto-upgraded
upon
using a 1.5 client? (presumably to do a merge)
This could cause lots of problems in that a project team may want to
stick
with 1.4 for a variety of reasons. Try as they might, they can't
prevent
the clever rogue user who wants to "try out" a shiny new 1.5 client only
to discover that they've hosed the rest of the project by triggering an
auto-upgrade.
On the other hand, an explicit upgrade process would be great. :^)
>
> It is inconvenient but I think less of an inconvenience then requiring
> everyone else to do something special.
>
> This is not a CollabNet issue either. Our repositories are BDB and if
> you decide not to include an upgrade process then we are perfectly
> capable of writing a script for our operations group that can handle
> this for the sites we manage. I am speaking purely as someone that
> has been involved for a long time and spent a lot of time helping
> users on the various mailing lists and forums. These current plans
> are going to cause a lot more problems than everyone seems to want to
> acknowledge.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>
>
---------------------------------------------------------------------
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 18:24:08 CET