From: Bojan Nikolic <bojan@bnikolic.co.uk>
To: emacs-devel@gnu.org
Subject: Re: Bzr document unclear. There is no "conflict markers".
Date: Mon, 04 Jan 2010 20:07:40 +0000 [thread overview]
Message-ID: <878wcdfxbn.fsf@bnikolic.co.uk> (raw)
In-Reply-To: E1NRpiQ-0004n8-6m@fencepost.gnu.org
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
Richard Stallman <rms@gnu.org> writes:
> The concept of "accepted into the trunk" puzzles me. If someone has
> write access, he can install his changes into the trunk, right? So if
> he has committed all his past changes, there's nothing to merge --
> right?
>
> Are you assuming the case of a person who doesn't have write access
> on Savannah?
Yes, I assumed this was the case, i.e., the developer of the quick-fix
sends his fix using the "bzr send" command and it isn't immediately
integrated onto the trunk.
To be more concrete, here is a little shell script which illustrates
this scenario and error message you get if you do not use "merge".
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: t1.sh --]
[-- Type: text/x-sh, Size: 1664 bytes --]
# Example for user without write access
# This branch represnts the true upstream trunk
bzr init upstream-trunk
# Add a first revision to trunk
(cd upstream-trunk && bzr commit --unchanged -m "Base rivision")
# This is the users' version of the trunk
bzr branch upstream-trunk trunk
(cd trunk && bzr bind ../upstream-trunk)
# This is the user's quickfixes branch
bzr init quickfixes
# Normal development continues on upstream-trunk...
(cd upstream-trunk && bzr commit --unchanged -m "Other peoples revision #1")
(cd upstream-trunk && bzr commit --unchanged -m "Other peoples revision #2")
# Now user wants to make a quick fix:
(cd trunk && bzr update)
# In this case, bzr pull works, because although there are new
# revisions in trunk, they all follow the last revision in quickfixes
# and so there isn't a divergance
(cd quickfixes && bzr pull ../trunk && bzr commit --unchanged -m "My fix #1")
# At this point the user would send their fix
# ( cd quickfixes && bzr send <email address>)
# Now assume the fix is not integrated on the upstream-trunk, but that
# development continues:
(cd upstream-trunk && bzr commit --unchanged -m "Other peoples revision #3")
# The developer wants to make another quick-fix. First update as before
(cd trunk && bzr update)
# Now, if (s)he tries to pull this will not work:
(cd quickfixes && bzr pull ../trunk && bzr commit --unchanged -m "My fix #2")
# The above does not work, because of divergance. You can visualise as:
(cd quickfixes && bzr graph-ancestry --no-collapse --merge-branch=../trunk quickfixes.png)
# But Merge will work
(cd quickfixes && bzr merge ../trunk && bzr commit --unchanged -m "My fix #2")
[-- Attachment #3: Type: text/plain, Size: 28 bytes --]
The graph it produces is:
[-- Attachment #4: Graph of revisions in the quickfixes and trunk branches, showing \"divergance\" --]
[-- Type: image/png, Size: 20792 bytes --]
[-- Attachment #5: Type: text/plain, Size: 188 bytes --]
The graph shows the "divergance" of the histories and the requirement
for merge. Hope it makes it clearer.
Best,
Bojan
--
Bojan Nikolic || http://www.bnikolic.co.uk
next prev parent reply other threads:[~2010-01-04 20:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-03 12:44 Bzr document unclear. There is no "conflict markers" Jan Djärv
2010-01-03 13:39 ` Eli Zaretskii
2010-01-03 14:33 ` Jan Djärv
2010-01-03 15:10 ` Eli Zaretskii
2010-01-03 19:17 ` Jan Djärv
2010-01-03 19:25 ` Eli Zaretskii
2010-01-04 0:14 ` Jan Djärv
2010-01-03 15:24 ` Bojan Nikolic
2010-01-03 21:59 ` Richard Stallman
2010-01-03 22:36 ` Bojan Nikolic
2010-01-04 16:23 ` Richard Stallman
2010-01-04 17:08 ` Stefan Monnier
2010-01-04 20:07 ` Bojan Nikolic [this message]
2010-01-04 4:08 ` Eli Zaretskii
2010-01-04 16:23 ` Richard Stallman
2010-01-04 18:27 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878wcdfxbn.fsf@bnikolic.co.uk \
--to=bojan@bnikolic.co.uk \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.