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

Re: Proposed New Features (FINAL)

From: Greg Stein <gstein_at_lyra.org>
Date: 2004-03-20 02:29:35 CET

On Fri, Mar 19, 2004 at 11:50:03PM +0100, Arild Fines wrote:
> Max Bowsher wrote:
> > Arild Fines wrote:
>...
> >> Is it? A .svnignore file wouldn't have to be versioned, meaning that
> >> different developers can have different ignore patterns set. Very useful if
> >> the developers are using different build environments.
> >
> > Why not just add all the relevant ignore patterns to the repository?
>
> But why should you be forced to version something that's essentially
> private? As long as svn:ignore has to be maintained server side, it is *not*
> a duplicate of the .svnignore proposal.

Well, we *do* have the "global-ignores" config option. That isn't specific
to a working copy, but it probably fits the bill.

> However, if SVN was to support the idea of a working-copy-only/nonversioned
> property(a --wc-prop flag to svn ps|pe, perhaps?), it would be a different
> matter. This could be useful in other situations as well - various
> Subversion clients could use it for maintaining working copy-specific
> metadata. I can think of at least one scenario where Ankh could find use for
> this.
>
> Was such a feature ever considered?

Nope. Precedent is to have a single union of all the types and put those
into the svn:ignore property. That concept seems to have worked quite well
for CVS (same model, different expression, though), so we didn't see a
need to go back for a rethink/redesign that may have resulted in your
alternative.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 20 02:27:40 2004

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.