On Mon, Aug 22, 2011 at 12:51 PM, Neels J Hofmeyr <neels_at_elego.de> wrote:
> On 08/22/2011 04:45 PM, Mark Phippard wrote:
> > On Mon, Aug 22, 2011 at 10:32 AM, Neels J Hofmeyr <neels_at_elego.de
> > <mailto:neels_at_elego.de>> wrote:
> >
> > Greg/anyone, do you have any more arguments against svn:hold except
> "people
> > will trip over a prop they read the documentation of and set up
> themselves
> > before it had any effect" -- because I don't think that's a real
> problem.
> > They would have tripped over 'svn:ignore', 'svn:externals' and
> > 'svn:keywords' long before tripping over 'svn:hold'. BTW, my
> intention is to
> > clearly mark held-back local mods in 'svn status' (e.g. 'H');
> particularly
> > important for merge situations.
> >
> > In my vision, 'svn:hold' would be the exception, in the scale of one
> > build.conf type of file per huge project tree. But that's up to the
> users.
> > Which is exactly the point!
> >
> > (See notes/hold for more points.)
> >
> >
> >
> > I really do not know where I stand on this. If you had asked me before
> you
> > started if it would be good to have a feature where certain local files
> > could be ignored by commit I would have said Yes. Now that you have
> started
> > working on it, and some more thought has gone into it I am less sure. I
> do
> > worry about the implications of a feature like this in terms of what the
> > behavior should be on other commands.
> >
> > Maybe a different implementation could make a difference? Just thinking
> out
> > loud ....
> >
> > What if SVN had a feature like TortoiseSVN where any file in a
> specifically
> > named changelist was automatically ignored on commit unless that specific
> > changelist is named ($ svn ci -cl ignored-files ) We could probably make
> > commands like status and diff automatically ignore this changelist too.
>
> Hi Mark,
>
> you first express concerns about implications on other commands, and then
> you propose the exact same feature and implications using changelists? Come
> on :)
>
> >
> > Perhaps we could then go a step farther with this feature by
> automatically
> > adding files with a special property like svn:hold to this changelist
> when
> > they are checked out?
>
> I thought about this too, actually, and came to this conclusion: it just
> inflates the whole implementation. Nothing more. The exact same thing can
> be
> achieved with *just* a property, without having to "rape" changelists: the
> changes to changelists would be: introduce special treatment of changelists
> that have a specific name (-1). Introduce reversable changelists (+1) but
> only do it implicitly, if it has one certain name (-1). *After* you did
> this, you put into life a property (where we already have a reserved
> namespace and long history for storing svn-internals), and instead of
> querying the prop directly, you have changelists inserted in the chain. I'm
> -1 to that.
>
I think there is a difference. By using a combination of svn:hold and
changelists the tool can do work for the user. Merge is the best example
(it might be the only example). When you do a merge, we could automatically
remove a file from the ignore changelist so that it would be committed by
default and not require the user to add a special option to their commit.
Commit could then put the file back on to the ignore list.
I do not think we have to use changelists to accomplish this. I was just
using that as an example. Using changelists does have a benefit that it
already has a lot of UI.
Wow, I didn't think I'd have to argue this much :)
> I still don't see how 'svn:hold' is problematic to include in 1.8.
> More cons?
>
I would not have expected this either. But I have to say that I am not
convinced that the benefits of this feature outweigh the negatives. Right
now, I think the negatives far exceed the positives. I think this feature
could actually wind up being very confusing to users.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-22 18:59:52 CEST