[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: depth of the operation vs. depth of the WC

From: Rui, Guo <timmyguo_at_mail.ustc.edu.cn>
Date: Sat, 5 Apr 2008 02:15:21 +0800

> > > Er, and also you're right that this is pretty important for the
> > > deselection interface when you're deselecting a child of something
> > > that isn't depth-empty (or a directory child of something that is
> > > depth-files).
> >
> > Maybe I'll try to bring in the depth-exclude in my deselection design
if
> > there is still enough time after I've done with existing depth values.
> > Anyway, this is another story and is not in my plan yet. :-)
>
> Yeah, I'm just not sure that it's good if
>
> $ svn co $REPO/trunk
> $ svn-exclude trunk/subdir
>
> suddenly means that "svn up trunk" won't add new subdirs ever.
This would be very bad in my opinion and I wouldn't let it happen. :-)
It's better to leave an empty sub-directory if we can't get rid of it
without negative side effect. The depth-exclude may come to rescue in such a
situation.

And your example here makes me think of something different. Even if the
user explicitly select a subset of subdirectories to work on, it will still
be beneficial to get the user notified if a possible relevant subdirectory
is added after the last update. For example
$ svn co --depth empty $RESPO/trunk
$ svn up A C //work in subdirectory A&C
// Someone added subdirectory D in $RESPO/trunk
// And a later 'svn up' should result in some notification about the added
directory, such as
A,Skipped D

I'm not sure if something like this has already been implemented.

Thank you
Rui, Guo

---------------------------------------------------------------------
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-04 20:15:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.