[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locks on the Bzr repository

From: Eli Zaretskii
Subject: Re: Locks on the Bzr repository
Date: Sun, 22 Aug 2010 04:52:14 -0400

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden
> Date: Sun, 22 Aug 2010 16:36:20 +0900
>  > I could use "ci --local", but that would cause my changes appear on
>  > a branch when I finally commit upstream, and require the -n0 switch
>  > to "bzr log", so I try to avoid that.
> isn't a problem if you rebase.

Stefan says bzr's rebase is unreliable.  I only used rebase in toy
use-cases, so I have no first-hand knowledge.  Perhaps Stefan could
elaborate on the problems he knows about.

>  > > The recommended workflow (at least as Karl and I wrote it)
>  > > assumed that "one-commit changes" would be performed in a
>  > > separate branch, and merged into the mirror (bound branch) in
>  > > batches.
>  > 
>  > This would again fly in the face of the "don't lump together..."
>  > request, AFAIU.
> Then there's something you don't understand.  What don't you
> understand?

I just completely misunderstood the use-case you were describing.
Re-reading it now, I don't see any problems of the "lumping" kind,
indeed.  The only problem is with having the changes on a branch
instead of mainline of the history, unless rebase is used.

There's one other problem with holding back commits to minor problems:
someone else could solve the same problem in the meantime.  Apart of
the obvious social issues ("I was the first to fix it"), there's the
issue of wasted effort.  With changes I make for the DOS port, I
casually leave them in a local commit for days, because I'm sure no
one else will touch them.  But with general-purpose changes, we need a
mechanism to announce "I'm working on this one", otherwise the urge to
commit the results of a job well done is too intense, I think.

If all of this were solved, I could probably wait with commits until
the end of the day, which will make the commit slowness much less of
an issue.

I guess no one seriously considered all these issues because we
believed (and still do) that bzr will eventually become faster on
Savannah.  Perhaps one day we will abandon that hope and turn to
resolving these issues instead.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]