[MERGE] no default ignores

[John Arbash Meinel]

Robert Collins wrote:
> 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. 

I agree that it is a little weird. I think it is more common to do:
bzr init; bzr add; bzr commit -m 'new project'
And we have been touting that as part of our simplicity.
However, with a tree that is only semi-clean, 'bzr init; bzr add' will
add lots of things that you probably don't want.

> 
> 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.

I'm happy enough with this. Older clients will be slower, but still
correct. And the whole point is for us to be going forward.
I would probably be just as happy with a:

===
!clear rules
*.o
*.py[co]
===

Where the '!clear rules' is a flag which removes all default rules. I'm
not especially partial to that exact text, but something like that may
be reasonable.
It would mean that old clients aren't compatible with trees that use
this feature.

But I would say 'performance degredation' with the # ignore format 2, is
probably the best route.

> 
>>> 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

I agree we need to address it. I don't want to see us lose our 'do the
right thing on init/add/commit'. Where it becomes 'init; configure your
ignore rules; add; commit'.

I think 'bzr init --defaults' is a reasonable step. Though in some ways
it is nicer to do the right thing with plain 'bzr init'. But it is
trickier. (If we had .bzrignore use a fixed id, it might be a little bit
better)

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060612/f1b91270/attachment.pgp