UI confusion / consistency

Robert Collins robertc at robertcollins.net
Fri Nov 23 03:54:26 GMT 2007


On Fri, 2007-11-23 at 13:23 +1100, Martin Pool wrote:
> > > Well, I agree about "ignore", but I think it should be equivalent to
> > > "add".  For "conflicts", we can't seem to agree about "status" display,
> > > so there's no point changing conflicts until then.
> > >
> > > Since we're a whole tree tool, I think we should show all changes.  But
> > > others think we should only show changes encompassed by the cwd.  I
> > > think that if your write operations are whole-tree, your read operations
> > > should also be.
> 
> It seems like we all agree that paths should always be shown relative
> to the cwd, so we can start on that regardless of the default scope of
> commands.

I think its possible to pay a very large price in string calculations
doing this, so we should be careful. 

> > My personal preference would be to have all operations work from cwd
> > down, by default - even operations like merge could do this in principal
> > with robust cherrypick suppport; that said today we're not there so
> > perhaps erroring on commands that could be partial by default when we
> > fix bugs would be sensible to avoid surprising people.
> >
> > OTOH what we have now works well and is pretty tasty (but I _very_
> > rarely cd into a subdir on projects I work on).
> 
> I also normally either commit the whole tree, or just specific files.
> I do sometimes work from one subdirectory.
> 
> I think you're right that merge and merge-like operations are the
> sticking point.  For example, would you really want 'pull' in a
> subdirectory to pull in only changes to that subdirectory?  Doing that
> would require svn-like support for a different basis revision for each
> file, and I'm not sure that's really desirable.

I don't think pull should be per-dir, because for pull to have completed
it does need everything moved forward -pull doesn't record a new graph
point, but merge prepares one, which is why I think merge is a candidate
for doing things on a per-dir basis.

> It would potentially be a surprising change when this happens, but not
> insurmountable and that shouldn't put us off assessing what's really
> best.

Agreed.

> Possibly we're over-generalizing from revert, and we should just make
> revert back up the discarded files...

I thought it already did?

> We can also communicate more, by making more commands explain what
> directory they're operating on, and what files are being affected.

Within limits, I agree with you.

-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: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20071123/8dca1190/attachment.pgp 


More information about the bazaar mailing list