Neels, I hadn't read through your 'notes/hold' doc, which I should have
done first. Now I have, and added a bunch of comments - see attached
patch.
It would be really helpful if, in the light of your current knowledge
and what's been discussed in this thread, you could update that doc and
convert it (or part of it) into a complete user reference manual
section, describing first the principles and then the exact intended
behaviour:
"The idea is X ... The new principles are X ... In terms of selecting
what to commit it works exactly like X except X ... The exact behaviour
of every affected operation is X ... Behaviours that might surprise you
at first are X ..."
You could put '### Not impl' or '### Currently does X instead of Y'
markers where applicable. Move possible alternatives into footnotes or
into a different section so we'd have a single complete description on
which to base any further discussion.
Where you replied to my question about diff:
> > And what's this about local-diff? You intend to ignore the whole
> > file that is 'held'? Or do you intend to print diffs of [...]
> I use 'svn diff' to check the local modifications that are going to be
> committed. Right?? How is it obscure to omit local modifications on a
> held-back file? (All mods that are already committed *are* shown.)
I was not saying we shouldn't affect diffs, I was asking exactly what
you intend, because I hadn't thought it through and it wasn't clear.
Now I've thought it through a bit more and put my notes in the attached
patch, but you may have more to say on it. I still don't understand
"All mods that are already committed *are* shown"; you can't be talking
about a local diff?
About copies: I've noted in the patch that I think copy should not
silently ignore local mods, because those mods might be intentional and
important. Instead, commit should error out, although I'm not precise
about the details. Maybe error on any attempt to commit the
add/del/cp/mv/replace of a held-back file if not overridden.
In my comments I say only the working props (and not the base props) of
the file should determine whether it's held back. That's because I
think that definition plays well with nearly all the other behaviour. I
first started to write things like "if the base and/or working version
has the prop ..." and that got messy and unnecessary. But I haven't
fully resolved how this affects deleting the file: a schedule-delete
file logically has no working props.
- Julian
Received on 2011-08-23 15:34:42 CEST