On Tue, 2008-09-23 at 22:47 +1000, Clint Lawrence wrote:
> On 23/09/2008, at 7:03 AM, Julian Foad wrote:
> > I am concerned about adding a chunk of code into the commit logic that
> > isn't closely aligned to the commit logic's task. In particular, I am
> > concerned about adding it into the library.
> >
[...]
> I was conscience of messing with the commit logic at first, but it felt
> like the path of least resistance at the time. This is my first crack
> at contributing here, so if I've taken the wrong path I'm happy try
> again.
That's great to hear! I thought I sounded a bit harsh saying that all
your good work so far wasn't the way I'd like to see it done.
> When I first looked at this, I was actually a little surprised that
> commit
> and status didn't share the same code to recurse through the wc. So I
> was
> (naively?) hoping that the commit logic would more or less have
> access to
> that information and was just throwing it away while it built the
> list of
> items to commit. I suppose thinking that shaped my approach to the
> problem.
>
> The only other advantage I can think of for putting it in the
> library, is
> that it becomes available to other users of the API. I don't think
> I'm in
> a position to judge if that would be useful or not
>
> >
> > Taking a step back, isn't the output of "svn status" what we want to
> > see? I'm not clear why we would want a special subset of it. Let me
> > give
> > some examples of what I mean:
> >
> > * Do we want to ignore items in the global-ignores and the local
> > svn:ignore list? Undoubtedly. Then we perhaps should support a
> > "--no-ignores" switch like "svn status" does. I can easily say, "No we
> > shouldn't - that's going too far," but where is the rationale behind
> > that decision?
>
> From a user interface point of view I'm not sure it would make sense
> to have a
> "--no-ignores" switch for "svn commit". I would read that to mean it
> some how
> effected what items would be committed. Of course the general point
> you raise
> is valid and I'm not sure I have a response to that at the moment.
>
> > * Where should we look for unversioned items? The present patch,
> > from
> > my quick glance, looks in each directory scanned for committables, and
> > also looks at the immediate siblings of each specified target. That's
> > fine for one user, but the next user wants to also see "cousins" like
> > "www/jpegs/unversioned.jpg" when committing "www/gifs/new.gif" as a
> > named target.
>
> Correct. That is where it looks at the moment. My inclination was to
> start
> out as simple as possible and provide something that helps in most
> cases. It
> is after all, just a reminder. How far should you go to protect
> people from
> themselves?
The point of all those questions was to illustrate that there is no
canonical answer. If we implement this feature using arbitrary answers
to those questions, it will satisfy some users but others will always be
wanting to change it in various ways. It would be better to write the
feature somewhere where technically inclined users can tweak it as they
want it.
> > * If we look for unversioned items because the user might have
> > forgotten to add them, why do we not also look for the opposite: items
> > that are "missing" because the user deleted or moved them without
> > telling Subversion?
> >
> Good idea. For myself, I'm usually forgetting to add something, but the
> symmetry is appealing.
>
> Some more constructive feedback on which direction to add would be very
> helpful for me at this point, if anyone has some to offer.
If you can, I would like to see if this can be implemented in a script
whose name is plugged in to the "SVN_EDITOR" environment variable. I
would recommend Python as a language to write it in. If you find that
plugging in to SVN_EDITOR doesn't give you access to the information you
need, discuss here and maybe we can generalise/change/extend the plug-in
support.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-24 18:15:36 CEST