Can we try to concentrate on the behaviour required, and not yet concern
ourselves with the implementation technology other than as a tool for
describing the behaviour? WC-DB columns are taboo in this thread :-)
As far as I know we are all talking about the following use case:
(1) An IDE configuration file (for example) is stored in the WC and it
is convenient for new checkouts to contain this file. The IDE typically
makes local changes to this file which would not be appropriate for
other users to see, such as a password or the directory to use for
temporary files. We don't want to commit these changes in a normal
commit. Occasionally, one of the developers wants to commit an
intentional modification to the config file. To do so, he/she will
revert the changes in that file that are specific to his/her username or
workstation or whatever, and carefully make and commit the desired
change. Other users expect to get any such changes when they do a
regular Subversion update. The file is assumed to be mergeable (text).
If anyone thinks there are other use cases, please speak up.
Neels wrote:
> - I strongly agree that we do *not* hold updates or anything else, except
> commit.
Sounds reasonable, based on the use case (1).
> (With wc-copies, we should probably not copy local mods though, and
> a diff of local mods should omit held-back stuff. But that's *all*.)
Why that? That's a significant extra semantic change.
[... and, later ...]
> it would affect:
>
> commit,
> local-diff,
> wc-to-* copy,
> merge (print warning to add --do-not-hold to the next commit
> OR set flag),
> update/switch (print warning if prop gets removed,
> iff there are local mods aka secrets).
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 the parts that were
merged but not diffs of the parts of it that were changed by the IDE?
(I'm joking, but only just.)
[...]
> - #svn, the issue tracker (and probably the users@ list too though I haven't
> checked) perpetually bring up this "template" problem. Tortoise has a per-WC
> solution; we just have dumb workarounds, really.
Issue numbers?
I haven't heard of this issue being referred to with the word
'template'. I've heard requests for log message templates, and I've
heard requests for 'views' that map a WC to a set of repos paths which
might sometimes be called 'templates'.
- Julian
Received on 2011-08-22 19:18:11 CEST