You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@vmoo.com> on 2007/10/05 11:59:48 UTC
RE: We should bump WC format version number for 1.5. - Merge tracking & Changelist support
[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:kfogel@red-bean.com]
> Sent: donderdag 4 oktober 2007 8:08
> To: dev@subversion.tigris.org
> 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
- keep_local (impacts directories only)
svn rm --keep-local dir
Won't keep directory
- working-size
svn status won't see changes when the timestamp has not changed but the file
size has.
===
All these items break if 1.4 and 1.5 clients are used on the same working
copy.
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: We should bump WC format version number for 1.5. - Merge
tracking & Changelist support
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-10-05 14:56:20 -0700, Daniel L. Rall wrote:
> However, enforcing a minimum client version isn't an unreasonable desire:
Enforcing a minimum client version is *impossible* with many Linux
distributions.
> For both these cases, as with --depth (or -N), information stored in
> the user's WC will be irrevocably lost. Record that you wanted to
> keep a path around after making it unversioned, or memory of those
> 37 files you'd added to a changelist would be wiped out.
I don't understand. Could you give an example?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: We should bump WC format version number for 1.5. - Merge tracking & Changelist support
Posted by Jack Repenning <jr...@collab.net>.
On Oct 5, 2007, at 3:14 PM, Daniel L. Rall wrote:
> On Fri, 05 Oct 2007, Jack Repenning wrote:
>
>>
>> On Oct 5, 2007, at 2:56 PM, Daniel L. Rall wrote:
>>
>>> However, enforcing a minimum client version isn't an unreasonable
>>> desire:
>>> 1.4 clients won't set mergeinfo for merge/copy/move operations,
>>> meaning
>>> that merge history will be lost (unless subsequently manually
>>> updated
>>> using 'svn propedit', something which I'd strongly recommend that
>>> the
>>> average user should not do, given our complex inheritance rules).
>>> You won't
>>> be any worse off than you were with 1.4, but it's annoying none the
>>> less.
>>
>> I think you will be very much worse off, because you will be
>> conditioned to suppose that the merge info is there, yet it is not.
>
> This is a pretty big assumption for a user who's mixing 1.5 and < 1.5
> tool chains. :-p
It's not about assumptions, it's about confusion. If the tools mix
behavior like this, and bearing in mind that Subversion has become a
richly embedded component, so we're talking about a mix of many
tools, not merely consciously variant versions of one, then the user
has no choice but to make up their own understanding of the models.
That, not to put too fine a point on it, is an appalling crock.
Users do not have access to the finely nuanced history of this mail
list, nor the energy to think these things through.
While I'm sympathetic to those developers who want to mix versions,
or find they must mix versions for various reasons, that can't be the
primary model: common things should be simple, and now that
Subversion has actual users in number far beyond its developers, the
common things have become the user things.
Uncommon things should, of course, remain possible, such as there
being some way to mix versions if you really have to. "Possible when
not simple" might mean "--force" options or such.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
Re: We should bump WC format version number for 1.5. - Merge tracking & Changelist support
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Fri, 05 Oct 2007, Jack Repenning wrote:
>
> On Oct 5, 2007, at 2:56 PM, Daniel L. Rall wrote:
>
> >However, enforcing a minimum client version isn't an unreasonable
> >desire:
> >1.4 clients won't set mergeinfo for merge/copy/move operations,
> >meaning
> >that merge history will be lost (unless subsequently manually updated
> >using 'svn propedit', something which I'd strongly recommend that the
> >average user should not do, given our complex inheritance rules).
> >You won't
> >be any worse off than you were with 1.4, but it's annoying none the
> >less.
>
> I think you will be very much worse off, because you will be
> conditioned to suppose that the merge info is there, yet it is not.
This is a pretty big assumption for a user who's mixing 1.5 and < 1.5
tool chains. :-p
More specifically, it will be a "problem" for other more knowledgable
users working with the same repository (they'll have to re-merge a set
of changes, once). But, it'll be no more of a "problem" than it was when
working with 1.4 and previous releases.
> If, for example, the merge unknowingly made with a 1.4 client
> included some non-conflicting changes that ought to be "mine" (as
> we're now learning to call it), and they were fixed up to be so by
> editing the merge-result file, then a subsequent 1.5-client merge
> will again apply the (presumably still non-conflicting) changes,
> silently.
Yes, and record the absent mergeinfo for those changs, "fixing" the
merge history.
Re: We should bump WC format version number for 1.5. - Merge tracking & Changelist support
Posted by Jack Repenning <jr...@collab.net>.
On Oct 5, 2007, at 2:56 PM, Daniel L. Rall wrote:
> However, enforcing a minimum client version isn't an unreasonable
> desire:
> 1.4 clients won't set mergeinfo for merge/copy/move operations,
> meaning
> that merge history will be lost (unless subsequently manually updated
> using 'svn propedit', something which I'd strongly recommend that the
> average user should not do, given our complex inheritance rules).
> You won't
> be any worse off than you were with 1.4, but it's annoying none the
> less.
I think you will be very much worse off, because you will be
conditioned to suppose that the merge info is there, yet it is not.
If, for example, the merge unknowingly made with a 1.4 client
included some non-conflicting changes that ought to be "mine" (as
we're now learning to call it), and they were fixed up to be so by
editing the merge-result file, then a subsequent 1.5-client merge
will again apply the (presumably still non-conflicting) changes,
silently.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
Re: We should bump WC format version number for 1.5. - Merge tracking & Changelist support
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Fri, 05 Oct 2007, Vincent Lefevre wrote:
> On 2007-10-05 15:13:48 +0200, Erik Huelsmann wrote:
> > On 10/5/07, Bert Huijben <be...@vmoo.com> wrote:
> > > 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.
>
> I don't think this is much a problem: merge tracking is already
> absent from 1.4. So, for 1.4 users (who need to use 1.5 clients
> too just because they are installed on some machines), there will
> be no practical change. Or is there anything I've missed?
In the case where you've got a 1.4 WC, unless you've made manual changes
to the "svn:mergeinfo" property on a path, changes pulled down from the
repository (e.g. via 'svn update') are not likely to conflict.
However, enforcing a minimum client version isn't an unreasonable desire:
1.4 clients won't set mergeinfo for merge/copy/move operations, meaning
that merge history will be lost (unless subsequently manually updated
using 'svn propedit', something which I'd strongly recommend that the
average user should not do, given our complex inheritance rules). You won't
be any worse off than you were with 1.4, but it's annoying none the less.
Using the WC format to help enforce a minimum client version isn't an
entirely unreasonable way to go here.
> > > 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.
>
> What would be the practical consequences for the user?
>
> > > - keep_local (impacts directories only)
> > > svn rm --keep-local dir
> > > Won't keep directory
> >
> > That too would be a problem.
>
> Same question.
For both these cases, as with --depth (or -N), information stored in the
user's WC will be irrevocably lost. Record that you wanted to keep a path
around after making it unversioned, or memory of those 37 files you'd added
to a changelist would be wiped out.
--
Daniel Rall
Re: We should bump WC format version number for 1.5. - Merge
tracking & Changelist support
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-10-05 15:13:48 +0200, Erik Huelsmann wrote:
> On 10/5/07, Bert Huijben <be...@vmoo.com> wrote:
> > 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.
I don't think this is much a problem: merge tracking is already
absent from 1.4. So, for 1.4 users (who need to use 1.5 clients
too just because they are installed on some machines), there will
be no practical change. Or is there anything I've missed?
> > 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.
What would be the practical consequences for the user?
> > - keep_local (impacts directories only)
> > svn rm --keep-local dir
> > Won't keep directory
>
> That too would be a problem.
Same question.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: We should bump WC format version number for 1.5. - Merge tracking & Changelist support
Posted by Erik Huelsmann <eh...@gmail.com>.
On 10/5/07, Bert Huijben <be...@vmoo.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:kfogel@red-bean.com]
> > Sent: donderdag 4 oktober 2007 8:08
> > To: dev@subversion.tigris.org
> > 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
> copy.
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...)
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org