Bzr document unclear. There is no "conflict markers".

Bzr document unclear. There is no "conflict markers".

[Jan Djärv]

Hi.

I tried to follow the worklflow for a quick change:

"Workflow for a Quick Change

First, refresh your mirror and then the working branch:

       cd $DEVHOME/emacs/trunk
       bzr update                     # update from the upstream master (optional)
       cd ../quickfixes
       bzr merge                      # update from /trunk/ (optional)

The reason you use “merge” instead of “update” in the task branch is that your 
task branch has local changes – it has diverged (a bit) from the upstream 
master, and so any changes from upstream have to be merged with your changes.

The merge may fail due to a change that conflicts with your branch. You’ll 
need to fix the problem (looking for conflict markers and editing, just as in 
CVS), then ..."

When I do the merge it just says:

% bzr merge
bzr: ERROR: Working tree "/home/jhd/src/bzr/emacs/fixes/" has uncommitted 
changes (See bzr status).

If I do bzr status, almost the whole tree is listed as modified (except files 
added and removed and not version controlled).

I certainly didn't modify all files, in fact I modified none.  I just tried to 
sync from savannah before starting to modify files.  Is this expected from 
bzr?  Should I create a new branch each time I sync from savannah, as reusing 
branches for fixes doesn't work?

	Jan D.

Re: Bzr document unclear. There is no "conflict markers".

[Eli Zaretskii]

> Date: Sun, 03 Jan 2010 13:44:59 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> 
> % bzr merge
> bzr: ERROR: Working tree "/home/jhd/src/bzr/emacs/fixes/" has uncommitted 
> changes (See bzr status).
> 
> If I do bzr status, almost the whole tree is listed as modified (except files 
> added and removed and not version controlled).
> 
> I certainly didn't modify all files, in fact I modified none.  I just tried to 
> sync from savannah before starting to modify files.  Is this expected from 
> bzr?

No.  Something is definitely wrong.  The workflow described on the
wiki works for me without any changes, including in a feature branch
where there are real non-trivial changes wrt the trunk.

Perhaps you somehow did something wrong while creating the branch.
If you start another branch, does "bzr status" show that all files are
modified, right after branching?  If not, when does it start showing
modified files?

> Should I create a new branch each time I sync from savannah

Certainly not.

Re: Bzr document unclear. There is no "conflict markers".

[Jan Djärv]

Eli Zaretskii skrev:
>> Date: Sun, 03 Jan 2010 13:44:59 +0100
>> From: Jan Djärv <jan.h.d@swipnet.se>
>>
>> % bzr merge
>> bzr: ERROR: Working tree "/home/jhd/src/bzr/emacs/fixes/" has uncommitted 
>> changes (See bzr status).
>>
>> If I do bzr status, almost the whole tree is listed as modified (except files 
>> added and removed and not version controlled).
>>
>> I certainly didn't modify all files, in fact I modified none.  I just tried to 
>> sync from savannah before starting to modify files.  Is this expected from 
>> bzr?
> 
> No.  Something is definitely wrong.  The workflow described on the
> wiki works for me without any changes, including in a feature branch
> where there are real non-trivial changes wrt the trunk.
> 
> Perhaps you somehow did something wrong while creating the branch.

I tried to follow the wiki, but it is of course possible.

> If you start another branch, does "bzr status" show that all files are
> modified, right after branching? 

No.

> If not, when does it start showing
> modified files?
> 

If I modify one file it just shows that as modified.  I can't reproduce the 
original error.  But it still doesn't show any conflict markers:

% bzr merge
bzr: ERROR: Working tree "/home/jhd/src/bzr/emacs/fixes/" has uncommitted 
changes (See bzr status).


I kind of expected merge to merge changes without me having to check in into 
the quickfix branch first.  Is there such a command?

	Jan D.

	Jan D.

Re: Bzr document unclear. There is no "conflict markers".

[Eli Zaretskii]

> Date: Sun, 03 Jan 2010 15:33:50 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: emacs-devel@gnu.org
> 
> If I modify one file it just shows that as modified.  I can't reproduce the 
> original error.  But it still doesn't show any conflict markers:
> 
> % bzr merge
> bzr: ERROR: Working tree "/home/jhd/src/bzr/emacs/fixes/" has uncommitted 
> changes (See bzr status).

I see that as well when I have uncommitted changes on a branch, so
it's probably normal.  Note that the wiki tells you to "bzr merge"
_before_ you start hacking.  But you are right that this issue should
be more explicit; I will edit the wiki (unless someone more
knowledgeable points out where we both are mistaken).

> I kind of expected merge to merge changes without me having to check in into 
> the quickfix branch first.

Why do you need that?  It is so easy to uncommit on a local branch
that committing there shouldn't be a hard decision.  It's not like you
are going to pollute a public repository.

> Is there such a command?

I don't know.

Re: Bzr document unclear. There is no "conflict markers".

[Bojan Nikolic]

Jan Djärv <jan.h.d@swipnet.se> writes:

> If I modify one file it just shows that as modified.  I can't
> reproduce the original error.  But it still doesn't show any conflict
> markers:
>
> % bzr merge
> bzr: ERROR: Working tree "/home/jhd/src/bzr/emacs/fixes/" has
> uncommitted changes (See bzr status).
>
>
> I kind of expected merge to merge changes without me having to check
> in into the quickfix branch first.  Is there such a command?
>

If I understand correctly, you want to first make edits to the files
that make up your fix, then merge, and then make one commit which
records all of this. You should be able to do that by passing the
--force option to merge (from man bzr):

   bzr merge [LOCATION]
       Options:

           --force                   Merge even if the destination tree has
                                     uncommitted changes.


I think it is usually better do the merge first (and resolve any
possible conflicts) before making the edits that make up your fix. If
you follow this procedure then there should be no need to --force.

Best,
Bojan


-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk

Re: Bzr document unclear. There is no "conflict markers".

[Jan Djärv]

Eli Zaretskii skrev 2010-01-03 16.10:
>> Date: Sun, 03 Jan 2010 15:33:50 +0100
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: emacs-devel@gnu.org
>>
>> If I modify one file it just shows that as modified.  I can't reproduce the
>> original error.  But it still doesn't show any conflict markers:
>>
>> % bzr merge
>> bzr: ERROR: Working tree "/home/jhd/src/bzr/emacs/fixes/" has uncommitted
>> changes (See bzr status).
>
> I see that as well when I have uncommitted changes on a branch, so
> it's probably normal.  Note that the wiki tells you to "bzr merge"
> _before_ you start hacking.  But you are right that this issue should
> be more explicit; I will edit the wiki (unless someone more
> knowledgeable points out where we both are mistaken).

Great.

>
>> I kind of expected merge to merge changes without me having to check in into
>> the quickfix branch first.
>
> Why do you need that?  It is so easy to uncommit on a local branch
> that committing there shouldn't be a hard decision.  It's not like you
> are going to pollute a public repository.

There is the question of commit logs and Changelogs.  There will be many local 
logs, and as I understood it from previous discussion, these will all 
propagate to savannah when I push from trunk.

	Jan D.

Re: Bzr document unclear. There is no "conflict markers".

[Eli Zaretskii]

> Date: Sun, 03 Jan 2010 20:17:44 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: emacs-devel@gnu.org
> 
> >> I kind of expected merge to merge changes without me having to check in into
> >> the quickfix branch first.
> >
> > Why do you need that?  It is so easy to uncommit on a local branch
> > that committing there shouldn't be a hard decision.  It's not like you
> > are going to pollute a public repository.
> 
> There is the question of commit logs and Changelogs.  There will be many local 
> logs, and as I understood it from previous discussion, these will all 
> propagate to savannah when I push from trunk.

But pushing from trunk is another operation.  "bzr merge" in the
branch merges latest changes from trunk _into_the_branch_, not the
other way around.  When time comes to merge your branch into mainline,
you should say "bzr merge ../quickfixes" _from_the_trunk_.  Only then
you need to worry about local logs etc.

Or am I missing something?

Re: Bzr document unclear. There is no "conflict markers".

[Richard Stallman]

    I think it is usually better do the merge first (and resolve any
    possible conflicts) before making the edits that make up your fix.

I find that hard to understand.  If you have not yet edited the file,
what is there to merge?  All you could do is update, right?

Is there something I don't understand here?

Re: Bzr document unclear. There is no "conflict markers".

[Bojan Nikolic]

Hi Richard,

Richard Stallman <rms@gnu.org> writes:

>     I think it is usually better do the merge first (and resolve any
>     possible conflicts) before making the edits that make up your fix.
>
> I find that hard to understand.  If you have not yet edited the file,
> what is there to merge?  All you could do is update, right?
>
> Is there something I don't understand here?

The quick answer is that the "quickfixes" branch could have diverged
from the trunk, for example because some of the developers changes have
not been accepted (yet) into the trunk.

Reviewing the wiki document, I do not it is completely clear on this
topic. The current text on the wiki on this is as follows
(http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc12):

          cd $DEVHOME/emacs/trunk
          bzr update                     # update from the upstream master 
          cd ../quickfixes
          bzr merge                      # update from /trunk/ (optional)

    The reason you use “merge” instead of “update” in the task branch is
    that your task branch has local changes – it has diverged (a bit)
    from the upstream master, and so any changes from upstream have to
    be merged with your changes.

I think there are a few things to add to this.

Firstly, it is not really correct that in the "quickfixes" directory
there is a choice between running "bzr merge" or "bzr update". In fact
(I believe) it is a choice between "bzr merge" and "bzr pull".

Recall, "bzr pull" can incorporate changes where there is no divergence
in history. In this case that will be true if the last revision
quickfixes is on the direct history line of the current last revision in
trunk.

If the histories have diverged, then "bzr merge" must be invoked to
combine them. One possible reason why the histories could have diverged
is that some of the changes that the developer has made on the
quick-fixes branch have not yet been accepted into trunk.

Secondly, if "bzr merge --pull " is called by the developer but "bzr
pull" would have succeeded (because in fact there has been no divergence
in history) then the results is exactly equivalent to "bzr
pull". Therefore I think in these situations it is better to do use the
--pull option to merge.

Best,
Bojan




-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk

Re: Bzr document unclear. There is no "conflict markers".

[Jan Djärv]

Eli Zaretskii skrev 2010-01-03 20.25:
>> Date: Sun, 03 Jan 2010 20:17:44 +0100
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: emacs-devel@gnu.org
>>
>>>> I kind of expected merge to merge changes without me having to check in into
>>>> the quickfix branch first.
>>>
>>> Why do you need that?  It is so easy to uncommit on a local branch
>>> that committing there shouldn't be a hard decision.  It's not like you
>>> are going to pollute a public repository.
>>
>> There is the question of commit logs and Changelogs.  There will be many local
>> logs, and as I understood it from previous discussion, these will all
>> propagate to savannah when I push from trunk.
>
> But pushing from trunk is another operation.  "bzr merge" in the
> branch merges latest changes from trunk _into_the_branch_, not the
> other way around.  When time comes to merge your branch into mainline,
> you should say "bzr merge ../quickfixes" _from_the_trunk_.  Only then
> you need to worry about local logs etc.
>
> Or am I missing something?
>

Probably not.  There has been so much discussion about workflows and such so 
it is a bit confusing.  I'll just see what happens when the time comes.

	Jan D.

Re: Bzr document unclear. There is no "conflict markers".

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 03 Jan 2010 16:59:59 -0500
> Cc: emacs-devel@gnu.org
> 
>     I think it is usually better do the merge first (and resolve any
>     possible conflicts) before making the edits that make up your fix.
> 
> I find that hard to understand.  If you have not yet edited the file,
> what is there to merge?

For the first edit ever in that branch, you are right.  But once you
begin working there, the histories of the branch and the trunk
diverge, so a merge is necessary.  Note that "merge" in Bazaar is not
just the merge of the files' contents, it is (AFAIU) also the merge of
histories of the branch and trunk, i.e. the DAG that represents the
history of each of the two trees is merged to include both.

Re: Bzr document unclear. There is no "conflict markers".

[Richard Stallman]

    The quick answer is that the "quickfixes" branch could have diverged
    from the trunk, for example because some of the developers changes have
    not been accepted (yet) into the trunk.

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?

Re: Bzr document unclear. There is no "conflict markers".

[Richard Stallman]

    For the first edit ever in that branch, you are right.  But once you
    begin working there, the histories of the branch and the trunk
    diverge, so a merge is necessary.

But after you commit your changes from the branch to the trunk,
isn't everything in sync until you start to edit again?

Re: Bzr document unclear. There is no "conflict markers".

[Stefan Monnier]

>     The quick answer is that the "quickfixes" branch could have diverged
>     from the trunk, for example because some of the developers changes have
>     not been accepted (yet) into the trunk.

> 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?

I have many changes on my local branch which the maintainers haven't
accepted yet.  Of course, could install them anyway since I have write
access, but Stefan would bite my head off if I did.


        Stefan

Re: Bzr document unclear. There is no "conflict markers".

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: bojan@bnikolic.co.uk, emacs-devel@gnu.org
> Date: Mon, 04 Jan 2010 11:23:57 -0500
> 
>     For the first edit ever in that branch, you are right.  But once you
>     begin working there, the histories of the branch and the trunk
>     diverge, so a merge is necessary.
> 
> But after you commit your changes from the branch to the trunk,
> isn't everything in sync until you start to edit again?

Maybe in theory.  Do you always commit _all_ your changes? don't you
sometimes leave some of them out because you are still working on them
or testing them?  And what about all those ChangeLog entries you made
while working in the branch -- won't you rewrite them at least to some
extent for committing to the trunk?

Besides, personally I'm not even sure ``everything is in sync'' even
if you commit everything.  I think that the DAG representing the
branch will still be different from the one representing the trunk,
due to local commits.  Somebody who knows more about bzr internals,
please confirm or refute this.

Re: Bzr document unclear. There is no "conflict markers".

[Bojan Nikolic]

[-- 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