[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Locks on the Bzr repository
From: |
Uday S Reddy |
Subject: |
Re: Locks on the Bzr repository |
Date: |
Fri, 20 Aug 2010 23:41:13 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 |
Perhaps I can sneak in a few comments while Stephen is offline. I have found
this debate quite enlightening and it helped me understand the limits of
"distributed" VCS. (I use unbound local branches in working on VM and always
wondered why you guys use bound branches. I am beginning to understand a
little bit now.)
On 8/20/2010 4:19 PM, Eli Zaretskii wrote:
Sure. So don't do that. One (probably for values of "one" != "eliz")
can pull instead, and rebase when necessary to get that to succeed.
Please show this workflow in more detail. Without the details, it's
hard to tell what you suggest. You could be thinking about things
possible with git, but not with bzr; it happened in the past.
I think one needs to do a pull before each commit, to be safe. (Seems to be
the same as update-commit cycle for bound branches.)
If you have already done a series of commits and lost the opportunity to pull,
then you have to rebase.
If even that seems too far out, then you have to make your changes into a
separate branch and merge it in later.
I don't use lightweight checkouts. I use one bound branch and 2 or 3
local branches. I have no problems with local commits, which I use a
lot. The problem happens when I need to commit to the master
repository. I need to do that from time to time, because my local
commits are not available to others, so if I fix bugs, my fixes will
not be good to anyone until I commit to upstream.
It seems to me that committing to the bound branch is essentially like push.
(Somebody said you were "discouraging" push. I don't see it. Your every
commit is a push.)
However, we get to use our local mirror of the trunk as if it were a local
branch. We can commit to it without affecting anybody else and do a public
commit only in the end. We can commit to it as often as we please, keep a
careful log, do enough testing etc. And, this local branch can magically turn
back into a proper mirror as soon as we do a rebase-push. You can't get this
with bound branches. Your local branches have to be necessarily separate
branches, whose histories will appear as merges in the mainline.
We use separate local branches as well, when they are appropriate. But we are
not forced to use them all the time. (Generally, I am happy to use the main
branch for a few days worth of work where I can see the end clearly. I use
separate branches for things that might take a few weeks, or things of a more
open-ended nature.)
And doing so is
painfully slow, and there seems to be no way around it. On top of
that, sometimes a commit fails, because someone holds a lock or
because some other commit was "sneaked" in in the meantime. So I need
to watch the commit and make sure it succeeds, or start another one if
it doesn't. So please don't tell me this is asynchronous, because it
isn't, at least not entirely.
Seems to me that you are reinforcing Stephen's point. With bound branches,
your branch is locked up until the commit goes through. You can't do anything
while you have uncommitted changes in your source. With unbound branches, we
can continue working on the source even when push is running in the background,
because the source tree doesn't have any uncommitted changes. We can also give
up on the push if necessary and continue committing to the branch. The
advantage seems quite clear to me.
No big deal. But the disadvantages of each workflow need to be well
understood before making a decision which one to use.
I can't believe that you guys really understood the disadvantages of your
current workflow before settling on it.
The most illuminating revelation I found in Stephen's post is that, with bound
branches, every commit is a merge. Most of the time, it is untested and
unsafe. This is the biggest disadvantage of all, if you ask me.
It also occurs to me that, by asking everybody to use bound branches, you have
massively increased the contention on your public repo and the server. That is
making your problems worse.
Cheers,
Uday
- Re: Locks on the Bzr repository, (continued)
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/20
- Re: Locks on the Bzr repository, Óscar Fuentes, 2010/08/20
- Re: Locks on the Bzr repository, Andreas Schwab, 2010/08/20
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/20
- Re: Locks on the Bzr repository, Andreas Schwab, 2010/08/20
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/20
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/20
- Re: Locks on the Bzr repository,
Uday S Reddy <=
- Re: Locks on the Bzr repository, Jan Djärv, 2010/08/21
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/21
- Re: Locks on the Bzr repository, Jan Djärv, 2010/08/21
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/21
- Re: Locks on the Bzr repository, Jan Djärv, 2010/08/21
- Re: Locks on the Bzr repository, Thien-Thi Nguyen, 2010/08/21
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/22
- Re: Locks on the Bzr repository, Thien-Thi Nguyen, 2010/08/22
- Re: Locks on the Bzr repository, Uday S Reddy, 2010/08/21
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/21