> > C. Michael Pilato wrote:
> >> Neels J Hofmeyr wrote:
> >>> Julian Foad wrote:
> >>>> Use case (2) - Eclipse folder, from issue #3028
> >>>>
> >>>> "For example we have a complete Eclipse instance in our svn
> >>>> repository and we want to ignore every change in its directory
> >>>> and below. [...]"
> >>>
> >>> That's quite a pickle. I'm not intending to make holding stuff recursive,
> >>> because then we'd have to check every commit target up into its ancestors,
> >>> possibly even checking if the *repos* has a hold set on an ancestor. Ugh.
[...]
> >>> And, my goodness, it *is* *already* possible to create a global hold on a
> >>> file using file externals. [...]
+1 on the idea of building a new feature on top of an existing
infrastructure. It reduces the cognitive load on the user. We need to
keep in mind that many users don't want or need to learn all about every
feature of Subversion. If a new feature can be described in two
sentences in terms of another feature, that's a *huge* win.
But ...
> >> Oh, dude. You're talking now about hacks based on hacks, here. It makes me
> >> hurt. :-)
... right, -0.9 on trying to use the externals code as such an
infrastructure, in its current state.
[...]
> >> So back to what I would consider the primary deliverable of interest here:
> >> avoiding one's own accidental commits. I'm leaning toward [...] A
> >> special changelist honored by our libsvn_client code which does what we're
> >> talking about here, shows up in 'svn status' like the others do, requires
> >> very little additional infrastructure, for which state changes are not
> >> versioned operations (such as they would be with the commits of the addition
> >> and removal of an svn:hold property), etc.
I like the sound of this, too, as the local-only part of the solution.
See below for the centralized part of the solution.
The set of changelists to use is already passed into the libsvn_client
API from the client. Pretty much all we need is a way to specify sets
of changelists more flexibly. For the main functionality, the 'commit'
subcommand would specify "select everything except changelist
'svn:ignore-on-commit'" unless overridden. That would make the file be
ignored on commit but otherwise not special (so it would show up in
diff, etc.).
And we could define a changelist 'svn:ignore-local-mods' that is ignored
in all operations that would normally see the local mods - diff, status,
copy, export, and even cat. Some of those operations might need to be
extended to honour changelists if they don't already. For these
subcommands the client might specify "all except changelists
svn:ignore-on-commit and svn:ignore-local-mods", unless overridden, for
example.
> Hyrum K Wright wrote:
> > [...] we'd need to support multiple
> > changelists on a single item before going this route. I wouldn't want
> > a special changelist to exclude standard ones.
I don't see a need for this file to belong to multiple changelists.
Belonging to changelist XXX says "The changes in this file are part of
feature/change/local-experiment XXX". If changes in this file are to be
ignored, then I don't see it making any sense for this file to belong to
any other changelist, unless and until the user decides that the changes
are not to be ignored.
Most of the time, the user will put the file in changelist
'svn:ignore-on-commit' and no other changes the user is making will want
to include that file. When the user wants to commit a change to that
file, he/she will either specify "--cl svn:ignore-on-commit" (with or
without other changelist(s), as appropriate) or will move this file into
a different changelist (or none) before commit and move it back into the
special changelist after commit.
Johan Corveleyn wrote:
> IMHO simply using changelists lacks the most important part of the
> feature: the ability to set/configure/annotate this centrally. [...]
Let's not dismiss changelists simply because they don't provide the
*whole* solution. This may sound like over-complication, but seriously
consider building on top of that. It's looking like changelists could
provide a decent solution for the local behaviour. On top of that, we
could provide exactly the 'svn:hold' property mechanism that Neels
already described, but instead of implementing checks for that property
directly, it could be treated as an instruction to the client to put the
file into the 'svn:ignore-on-commit' changelist (detail: if it's not
already in a changelist).
I think it's worth fleshing out a proposal using this approach.
- Julian
Received on 2011-08-24 12:14:04 CEST