On Fri, Aug 19, 2011 at 7:12 PM, Neels J Hofmeyr <neels_at_elego.de> wrote:
> On 08/19/2011 01:45 PM, Markus Schaber wrote:
> > Hi, Neels,
> >
> > Von: Neels J Hofmeyr [mailto:neels_at_elego.de]
> >>
> >> if I understand you correctly, you are saying that there's no need for
> >> svn:hold, as changelists already do what they are supposed to do.
> >>
> >> But changelists and svn:hold have entirely different use cases.
> >>
> >> 1) svn:hold is exclusive, changelists are inclusive.
> >> I mean you can use an svn:hold on *one* file to block it, or you'd
> >> have to add *all other* files to a change list, what a bummer.
> >
> > At least this usecase is supported by TortoiseSVN via the
> > "ignore-on-commit" changelist.
>
> Yes, I'm very aware of that. But I respectfully disagree with changelists
> being the best solution for this issue.
>
> <rant>Changelists could have been a nice solution if we had any
> repository-supplied config for those, and if it didn't involve reversing
> the
> currently established "direction" of changelists depending on the
> changelist
> name, and if it didn't involve using a changelist implicitly. All I see
> there are cans of worms and pandora's boxes. Using an "svn:"- prefixed
> property is more powerful, cleaner *and* easier to realize.</rant>
>
> But while we're at it, could you tell me if Tortoise's ignore-on-commit
> changelist also keeps out updates on those files? From the name I'd guess
> not, right? And does it affect WC-to-URL copies, or *anything* else?
>
> And, oh yes, if a folder appears in the ignore-on-commit list, are prop
> changes on that folder ignored on commit? And does that act recursively,
> keeping entire subtrees out of commit?
>
First off, +1 on the idea of doing a feature like this. The fact that
TortoiseSVN has coded something should be irrelevant. A solution that is
honored by the API would be much preferred as then you could have consistent
behavior across all clients. I am sure TortoiseSVN would prefer to remove
code and allow the API to handle parts of this as well.
That said, some of these questions concern me. Have you outlined your
vision for this feature in its entirety? The idea that svn up would not
update these files scares me. I have never heard anyone ask for anything
but having an easy way to exclude some files from commit. IMO, other
operations like update/merge/switch ought to all do their normal behavior
and not be impacted by a special property.
I also wonder about commit performance. Does WC-NG make this a non-issue?
I would imagine having to do a property check on every file could become
expensive, but at the same time with a focused and tuned SQL query it could
probably be negligible.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-20 03:14:11 CEST