On Mon, Apr 28, 2008 at 05:57:52PM -0400, Karl Fogel wrote:
> "Rui, Guo" <timmyguo_at_mail.ustc.edu.cn> writes:
> >
> > Well, it's a hard decision here and I'm not sure that I made the right
> > decision. The standpoint is that svn_wc_add2() is used in many
> > situations: add, merge and copy etc. The depth only makes sense in a
> > small piece of situations. That is, adding a directory (not files,
> > which should be much more than dir) in 'svn add' command. If such a
> > parameter is introduced, most of the time it only add the burden to
> > the caller (to fill in a nonsense) and looks ugly.
>
> I think I made my earlier decision about svn_wc_add2() without all the
> information we have now. If it just took a 'depth' argument, we could
> ignore it for files (or we could require that files be called with
> 'svn_depth_unknown' and check for it, to sanity-check the caller).
>
> Possibly other uses (outside of 'svn add') might also find the 'depth'
> argument useful. In any case, once we admit that addition of a
> directory is an operation involving depth questions, we might as well
> reflect that in the API. If many callers have to pass
> svn_depth_infinity, at least that's readable.
Ok, I'll introduce a new svn_wc_add2() and deprecate the current version. I
would just ignore the depth for files. (If I have to pay special attention to
files and prepare a 'svn_depth_unknown', I would like to suggest splitting the
API instead.) You are right in the sense that the API should be reflective and
may be useful in the future.
Personally, I do not like the idea of passing parameters which are just to be
ignored. However, this is an underlying design issue and does not concern me.
If you guys are really going to re-design the wc library, I think splitting
the API may be desirable, since the current one looks too heavy to me. Anyway,
that would be another story. :-)
>
> > An alternative should be just introduce a specialized svn_wc_add_dir()
> > only for 'svn add' and don't make it deprecate svn_wc_add2() (as we
> > generally do when we introduce something like svn_wc_add3()). Does
> > this seem to be a better choice? In this way, the default_and_fix way
> > will still have to be used, to reuse the implementation in
> > svn_wc_add2(). However, this dirty trick will not expose to the
> > client.
>
> Well, we'd want the depth as we're crawling down and doing the add, so
> we can avoid doing more work than necessary.
The API does not do the crawling; it just add the specified target. The
crawling is handled by the caller instead.
>
> Basically, I think just adding depth to the regular add API is okay.
Yes, basically I'm agree with you at this point.
>
> >
> > Well, this is a hard decision too, just as the decision to patch 'svn
> > add' itself. :) I think it makes sense to add the parent as empty. If
> > the user cares about something directly under the parent directory,
> > why not add the entire parent tree in the first place?
>
> Either empty or infinity.
>
> Actually, I think infinity may be better. Imagine that you
>
> svn add --depth=files --parents NEW_DIR_1/NEW_DIR_2/FINAL_DIR
> svn commit -m "...blah blah blah..."
>
> There might be a lot of subdirectories under FINAL_DIR, but they won't
> be added, only FINAL_DIR itself and its file children. Great.
>
> But later, after you do that, someone else adds NEW_DIR_1/FISH/ to the
> repository. What should happen if you run 'svn up' now?
>
> I think you should receive NEW_DIR_1/FISH. The alternative is that you
> don't find out that someone has been adding things in the directory you
> created -- which would be fine if you'd *requested* that directory with
> a limiting depth, but you didn't. The '--depth=files' in the original
> 'svn add' really referred to the final target, not to the intermediate
> stuff -- the intermediate dirs are just things you had to add in order
> to position FINAL_DIR correctly. If stuff appears in those intermediate
> directories later, you'd probably like to know. Not definitely, but
> probably.
I'm agree with you again, Karl. It's better to leave them infinity at current
time, even though the directories are logically added at empty.
This is just once again the same argue that whether we should apply the depth
to the new added directory. That's why I think it's handy to have a
notification mechanism. The difference this time is that the user does not
explicitly specify the depth for parent directories. (In fact, they do not
have a way to specify this, expect to use the traditional step by step way)
Since the user does not explicitly request it, and we do not have a mechanism
to notify them yet, it's better to leave it untouched.
>
> >
> > As you have mentioned previously in this thread. Whatever we choose to
> > do in the code, the user may complain in a oppose direction. Why not
> > give them a notice if we choose to preclude the update? This may
> > relieve their anger. :-)
>
> I just think we have more important things to do right now. This might
> be a nice feature, but it is unimportant compared to, say, a depth
> deselection interface :-).
Well, this idea just come to my mind when I was thinking about the semantics
of the --depth option. And I think it's valuable to share it with you. I'm not
saying that I would like to do it right now, even though I'm indeed
interested. The de-selection interface will always be my first priority until
it's settled.
>
> > This feature will need to tune the API. However, since the
> > notification only happens at the boundary that is defined by the
> > ambient depth of wc (in other words, we don't need to dig into
> > excluded sub-trees), it's possible to make it available with only
> > implement level modification. The "tell the repository to give me a
> > very finely-tuned directory delta" semantics should still be
> > maintained.
>
> I'm not sure exactly what you meant. Could you give an example?
Take the greek tree as an example. Consider a wc with directory A at
immediates and revision 1. And somebody introduced items A/D/new1 and
A/B/E/new_tree at revision 2. When we update our wc from revision 1 to 2, we
will notice the skipped new item A/D/new1 but not the A/B/E/new_tree. The idea
is that, if we include a directory in wc (a leaf directory in wc), we should
be able to see what happens (piratical) to it and probably would like to. If
we didn't bother to include the directory in wc, we are probably not
interested at all.
In such a way, the server do not need to crawl into unrelated path and thus
maintains the current way it works. The only extension is that the server will
have to feedback a little more when handling leaf directories in wc. However,
this behavior should be explicitly requested by client and should be still
considered 'finely-tuned directory delta'.
Did I make it clear enough?
Thanks,
Rui, Guo
PS: The new patch to 'svn add' will be delayed to this weekend. Because I have
a three-day vacation, the May Day in China, and would like to have a short trip.
Hope that this delay is not too much.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-29 11:37:13 CEST