On 10/5/07, Bert Huijben <email@example.com> wrote:
> [Another version of this mail will follow in a couple of hours; it is
> waiting for moderation as I used another mail address]
> > -----Original Message-----
> > From: Karl Fogel [mailto:firstname.lastname@example.org]
> > Sent: donderdag 4 oktober 2007 8:08
> > To: email@example.com
> > Subject: We should bump WC format version number for 1.5.
> > When I started writing this mail, it was a question: "Should we bump
> > the wc format number for 1.5?"
> > Now I've done some investigation, and I think it's a statement
> > instead. Despite my ardent desire that we not bump the format number,
> > we may have to. (There *might* be a way to conditionalize it; search
> > for "escape hatch" later in this mail to read about that.)
> When I look through this thread I think we forget two other important
> feature of the 1.5 release: We started using merge tracking & changelists.
> Merge tracking will give 1.4 clients+users a hard time on updates and merges
> as they don't have any builtin merge support for the svn:mergeinfo property.
> (See my other mail: 1.5 clients update this property on merges, copying,
> etc. and merge this property automatically.. 1.4 clients can only use it as
> an ordinary property)
> Looking through svn_entries I found these other wc additions since 1.4.X:
> - changelist
> File registration on a changelist is reset
Yes, I guess that would be a problem.
> - keep_local (impacts directories only)
> svn rm --keep-local dir
> Won't keep directory
That too would be a problem.
> - working-size
> svn status won't see changes when the timestamp has not changed but the file
> size has.
This is not a problem: the 1.5 client just won't perform any better at
detecting changes than the 1.4 client would... It's not a regression
or a real problem, but definitely a pity.
> All these items break if 1.4 and 1.5 clients are used on the same working
Yes. Thanks for completing the list.
The list above makes me think we should require wc-format upgrade on
all write operations, but only if the user explicitly chooses to do
so. (Better said: we should require the right format for all write
ops, erroring if it's not. Then 'svn cleanup --some-flag' could be
used to do an explicit upgrade...)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Oct 5 15:14:07 2007