[MERGE] no default ignores

[Robert Collins]

On Mon, 2006-06-12 at 10:18 -0400, Aaron Bentley wrote:



>I think this is overly boolean.  No design choice we make will be right
>for everyone, but still we work on bzr, in the hope that it will be
>right for the vast majority of people.

>You could argue that doing this would hurt performance, and I'd accept
>that.  But I think the number of people who want to version
> control .swp
>files approaches zero, and asking them to remove '*.swp' 
>from .bzrignore
>or do 'bzr init --no-defaults' would not be unreasonable.

'bzr init'; 'bzr add foo'; 'bzr commit -m bar' is a reasonable command
sequence. If .bzrignore is present by default, and added by default, we
now have two trees created by 'bzr init' not being equal, or having a
known, fixed id.

If its not added by default then the commit step will show an unknown
file which may surprise people. 

Neither seems particularly nice. Including any rules in the users tree,
with a versioned file controlling them seems fragile to me, and I'd much
prefer the versioned-data approach here too.

> > This is a lot more involved that it sounds: at a minimum it involves a
> > new repository format...
> 
> Why?  It's just a file in the user's directory.  Old bzrs won't
> understand it, but new ones will.  It seems like a better tradeoff than
> having everyone's ignore lists break when they upgrade their bzr.

If I have a tree with .bzrignore containing
===
# ignore format 2
rules here
===

Old clients will end up with even more rules than desirable, because of
the doubling of whatever rules people have included, and users of those
trees with older bzr will not add in the rules that are needed to ignore
files they see as automatically ignored in newer clients.

> > Jan Hudec has done a lot of work on a clean way
> > to transform .bzrignore into versioned data instead of being a versioned
> > file, and I think we should continue with that with the intent to merge
> > bits of it as they mature, or all of it eventually.
> 
> IIRC, you were the one who objected to any changes that might affect the
> ignore list even slightly.  It seems strange that you're now advocating
> a change that will break everyone's ignore lists, without providing an
> upgrade path.

Dont get me wrong here : I'm extremely *not pro* this per se - but I see
it as the best of a number of evils in the short term.

But we are heading down the rabbit hole here.... 

 * Ignores need to be addressed.
 * Its going to take a lot of work to make them significantly faster
(20% is not significant a this scale, we need a time reduction of
80-90%).
 * I'm happy to +1 pretty much anything that addresses them without
being ugly. This patch is a reasonable balance of effort/reward at this
point - and nothing precludes more work being done after it goes in.
 * I'd much rather have no default rules than some defaults, if only so
that there is no pressure to grow the list - its easier to say 'we dont
do defaults', than to say 'no Timmy, .foo cannot be a default' over and
over again.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060613/f7c7bc0b/attachment.pgp