TBrowder wrote:
> I appreciate all the comments, and have no defense except I read the
> developer section of the book as well as HACKING and obviously didn't read
> them thoroughly enough. I will make the corrections suggested and
resubmit.
> (And Julian, thanks for your kind words.)
>
> However, before I resubmit the patch, I'll discuss my proposal in more
detail.
>
> Sometime last year (on the users list) I asked about three features we use
> heavily with CVS:
It is good idea to keep email threads to a single concept. It makes the
discussion far easier to follow.
Accordingly, I'm replying to your mail:
"Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision
Aliases)"
in three seperate replies:
1. "Re: Proposed New Feature (SVNROOT)"
2. "Re: Proposed New Feature '.svnignore'"
3. "Re: Proposed New Feature 'rtag' (Revision Aliases)"
and I encourage people to continue discussion in each subthread seperately.
This is reply 2 of 3.
> .cvsignore
>
> I've tried the method described in the book and (1) it didn't work
and
> (2) I don't agree with it.
Please give much more detail. How didn't it work, and why don't you agree
with it.
> In the future I shall propose implementation of the other two features I
> would like. Here are my initial thoughts on those:
>
> .svnignore
>
> Similar to CVS except better (allow .svnignore to apply to directories):
> When the default 'svn status' command is given, for each directory first
> check for the presence of the file '.svnignore' and use the limited
regular
> expressions inside to check files and dirs that are unknown to svn (for
> "recursive" behavior, require an absolute or relative path to the file
> expression). Do not include those files in the resulting list.
How is this different to the svn:ignore property that we have already?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 17 15:11:05 2004