> > 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
