[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.
- Re: Locks on the Bzr repository, (continued)
- Re: Locks on the Bzr repository, Richard Stallman, 2010/08/25
- Re: Locks on the Bzr repository, Juanma Barranquero, 2010/08/25
- Re: Locks on the Bzr repository, Richard Stallman, 2010/08/31
- Re: Locks on the Bzr repository, Chong Yidong, 2010/08/31
- Re: Locks on the Bzr repository, Bernardo Barros, 2010/08/31
- Re: Locks on the Bzr repository, Miles Bader, 2010/08/31
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/31
- Re: Locks on the Bzr repository, Uday S Reddy, 2010/08/25
- Re: Locks on the Bzr repository, Richard Stallman, 2010/08/27
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/22
- Re: Locks on the Bzr repository,
Eli Zaretskii <=
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/22
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/22
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/22
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/22
- Re: Locks on the Bzr repository, Jan Djärv, 2010/08/22
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/22
- Re: Locks on the Bzr repository, Jan Djärv, 2010/08/22
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/20
- bzr smart server [was Re: Locks on the Bzr repository], Glenn Morris, 2010/08/20
- Re: bzr smart server [was Re: Locks on the Bzr repository], Lennart Borgman, 2010/08/20