bazaar

bazaar

[Carles Pina i Estany]

Hello,

I have to go to sleep now, but I've realized about a mistake or at least
unexpected behaviour.

After merging trunk with people/carles/gettext as Robert said I have been
committing and pushing a couple of things to people/carles/gettext. But I think
that after I merged it trunk now is always merged with carles/gettext .

revno 1848 and 1849 in trunk are pushes to my branch (or at least this
was my intention). After a clean checkout from trunk, doing bzr log:

------------------------------------------------------------
revno: 1849
committer: Carles Pina i Estany <carles@pina.cat>
branch nick: carlesgettext
timestamp: Sun 2009-11-22 23:41:06 +0000
message:
  2009-11-22  Carles Pina i Estany <carles@pina.cat>
  
        * normal/menu_text.c (get_spaces): New function.
        (print_timeout): Gettextize, add spaces to the localized string.
------------------------------------------------------------
revno: 1848
committer: Carles Pina i Estany <carles@pina.cat>
branch nick: carlesgettext
timestamp: Sun 2009-11-22 22:24:54 +0000
message:
  2009-11-22  Carles Pina i Estany <carles@pina.cat>
  
        * normal/menu_text.c: Gettexttize but not print_timeout function.
        * normal/main.c: Gettexttize.
        * normal/menu_entry.c: Likewise.
------------------------------------------------------------

1848 should be fine but I sent some hours ago a mail to discuss and
confirm it. So we should check, etc. 1849 is a file to track my changes
but not in trunk

How we proceed? Should I stop working with people/gettext ?
Should we "unmerge" and merge?

Thank and apologizes for the bazaar messes ups, 

-- 
Carles Pina i Estany
	http://pinux.info

[URGENT] Re: bazaar

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

Carles Pina i Estany wrote:
> Hello,
>
> I have to go to sleep now, but I've realized about a mistake or at least
> unexpected behaviour.
>
> After merging trunk with people/carles/gettext as Robert said I have been
> committing and pushing a couple of things to people/carles/gettext. But I think
> that after I merged it trunk now is always merged with carles/gettext .
>
> revno 1848 and 1849 in trunk are pushes to my branch (or at least this
> was my intention). After a clean checkout from trunk, doing bzr log:
>
> ------------------------------------------------------------
> revno: 1849
> committer: Carles Pina i Estany <carles@pina.cat>
> branch nick: carlesgettext
> timestamp: Sun 2009-11-22 23:41:06 +0000
> message:
>   2009-11-22  Carles Pina i Estany <carles@pina.cat>
>   
>         * normal/menu_text.c (get_spaces): New function.
>         (print_timeout): Gettextize, add spaces to the localized string.
> ------------------------------------------------------------
> revno: 1848
> committer: Carles Pina i Estany <carles@pina.cat>
> branch nick: carlesgettext
> timestamp: Sun 2009-11-22 22:24:54 +0000
> message:
>   2009-11-22  Carles Pina i Estany <carles@pina.cat>
>   
>         * normal/menu_text.c: Gettexttize but not print_timeout function.
>         * normal/main.c: Gettexttize.
>         * normal/menu_entry.c: Likewise.
> ------------------------------------------------------------
>
> 1848 should be fine but I sent some hours ago a mail to discuss and
> confirm it. So we should check, etc. 1849 is a file to track my changes
> but not in trunk
>
> How we proceed? Should I stop working with people/gettext ?
> Should we "unmerge" and merge?
>
> Thank and apologizes for the bazaar messes ups, 
>
>   
Looks like the mess is actually more profound than you describe. You
replaced our mainstream with your branch. Looks like bzr failed at its
primary task: protect against unintentional or intentional  deletion of
files.  We should think of a way to make trunks and experimental branch
commit-only. Meanwhile nobody pushes until further notice. I'll see how
it can be recovered and protected.
Robert: What is your latest backup before this accidental replacement?


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

[ISSUE SOLVED] Re: bazaar

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Carles Pina i Estany wrote:
>   
>> Hello,
>>
>> I have to go to sleep now, but I've realized about a mistake or at least
>> unexpected behaviour.
>>
>> After merging trunk with people/carles/gettext as Robert said I have been
>> committing and pushing a couple of things to people/carles/gettext. But I think
>> that after I merged it trunk now is always merged with carles/gettext .
>>
>> revno 1848 and 1849 in trunk are pushes to my branch (or at least this
>> was my intention). After a clean checkout from trunk, doing bzr log:
>>
>> ------------------------------------------------------------
>> revno: 1849
>> committer: Carles Pina i Estany <carles@pina.cat>
>> branch nick: carlesgettext
>> timestamp: Sun 2009-11-22 23:41:06 +0000
>> message:
>>   2009-11-22  Carles Pina i Estany <carles@pina.cat>
>>   
>>         * normal/menu_text.c (get_spaces): New function.
>>         (print_timeout): Gettextize, add spaces to the localized string.
>> ------------------------------------------------------------
>> revno: 1848
>> committer: Carles Pina i Estany <carles@pina.cat>
>> branch nick: carlesgettext
>> timestamp: Sun 2009-11-22 22:24:54 +0000
>> message:
>>   2009-11-22  Carles Pina i Estany <carles@pina.cat>
>>   
>>         * normal/menu_text.c: Gettexttize but not print_timeout function.
>>         * normal/main.c: Gettexttize.
>>         * normal/menu_entry.c: Likewise.
>> ------------------------------------------------------------
>>
>> 1848 should be fine but I sent some hours ago a mail to discuss and
>> confirm it. So we should check, etc. 1849 is a file to track my changes
>> but not in trunk
>>
>> How we proceed? Should I stop working with people/gettext ?
>> Should we "unmerge" and merge?
>>
>> Thank and apologizes for the bazaar messes ups, 
>>
>>   
>>     
> Looks like the mess is actually more profound than you describe. You
> replaced our mainstream with your branch. Looks like bzr failed at its
> primary task: protect against unintentional or intentional  deletion of
> files.  We should think of a way to make trunks and experimental branch
> commit-only. Meanwhile nobody pushes until further notice. I'll see how
> it can be recovered and protected.
> Robert: What is your latest backup before this accidental replacement?
>
>   
I managed to unmerge our mainstream by using raw revid (visible with bzr
log -n0 --show-ids) by
bzr branch -r revid:<..revid..> mainline mainline-real
If you comitted recently please check if nothing is missing
Carles: check your locations in
.bzr/branch/branch.conf


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: [ISSUE SOLVED] Re: bazaar

[Robert Millan]

On Mon, Nov 23, 2009 at 02:40:28AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> I managed to unmerge our mainstream by using raw revid (visible with bzr
> log -n0 --show-ids) by
> bzr branch -r revid:<..revid..> mainline mainline-real
> If you comitted recently please check if nothing is missing
> Carles: check your locations in
> .bzr/branch/branch.conf

Thanks Vladimir.  Btw, there's also "bzr uncommit".

Carles, can you explain the sequence of commands you used for this to happen?
I think I told you yesterday not to use "bzr push", and I can't think of
another way that would lead to this.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [ISSUE SOLVED] Re: bazaar

[Carles Pina i Estany]

Hi,

On Nov/23/2009, Robert Millan wrote:
> On Mon, Nov 23, 2009 at 02:40:28AM +0100, Vladimir '??-coder/phcoder' Serbinenko wrote:
> > I managed to unmerge our mainstream by using raw revid (visible with bzr
> > log -n0 --show-ids) by
> > bzr branch -r revid:<..revid..> mainline mainline-real
> > If you comitted recently please check if nothing is missing
> > Carles: check your locations in
> > .bzr/branch/branch.conf
> 
> Thanks Vladimir.  Btw, there's also "bzr uncommit".
> 
> Carles, can you explain the sequence of commands you used for this to happen?
> I think I told you yesterday not to use "bzr push", and I can't think of
> another way that would lead to this.

I'm not in home now, but I'm very sure that I did:

bzr checkout of trunk (fresh checkout)
1.- cd grub
2.- bzr merge sftp://..... people/carles/gettext (as I understood from you
in IRC)

After some other things, I worked in carles/gettext in other things and
I did:
3.- cd carles/gettext (I had this from before)
4.- bzr pull of trunk??? (I don't think so)
5.- bzr commit
6.- bzr push (without any URL)

I used push but only in my branch.

I'm thinking if in some point (so point 3) I didn't move to
carles/gettext or if I in point 6 I wrote the trunk URL. These are the
only possible mistakes that I can think (possible but I think that I did
correctly)

I have all branches in home, if I can verify something for you I would
do at the evening.

-- 
Carles Pina i Estany
	http://pinux.info

Re: [ISSUE SOLVED] Re: bazaar

[Robert Millan]

On Mon, Nov 23, 2009 at 10:59:34AM +0100, Carles Pina i Estany wrote:
> 
> bzr checkout of trunk (fresh checkout)
> 1.- cd grub
> 2.- bzr merge sftp://..... people/carles/gettext (as I understood from you
> in IRC)

These two by themselves don't modify the remote tree (you'd need bzr commit)

> After some other things, I worked in carles/gettext in other things and
> I did:
> 3.- cd carles/gettext (I had this from before)
> 4.- bzr pull of trunk??? (I don't think so)
> 5.- bzr commit
> 6.- bzr push (without any URL)

bzr push without any URL uses an implicit value, which *could* be our remote
trunk (use bzr info to check).  Always use an explicit value when pushing, or
check first with bzr info!

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [ISSUE SOLVED] Re: bazaar

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

Robert Millan wrote:
> On Mon, Nov 23, 2009 at 02:40:28AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>   
>> I managed to unmerge our mainstream by using raw revid (visible with bzr
>> log -n0 --show-ids) by
>> bzr branch -r revid:<..revid..> mainline mainline-real
>> If you comitted recently please check if nothing is missing
>> Carles: check your locations in
>> .bzr/branch/branch.conf
>>     
>
> Thanks Vladimir.  Btw, there's also "bzr uncommit".
>
>   
Probably wouldn't have helped. Trunk was replaced by Carles' branch and
original trunk was available only as a merge into this branch
> Carles, can you explain the sequence of commands you used for this to happen?
> I think I told you yesterday not to use "bzr push", and I can't think of
> another way that would lead to this.
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: [ISSUE SOLVED] Re: bazaar

[Robert Millan]

On Mon, Nov 23, 2009 at 02:40:28AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> I managed to unmerge our mainstream by using raw revid (visible with bzr
> log -n0 --show-ids) by
> bzr branch -r revid:<..revid..> mainline mainline-real

Btw with "mainstream" and "mainline", I assume you refer to trunk?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [URGENT] Re: bazaar

[Colin D Bennett]

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

On Mon, 23 Nov 2009 02:19:24 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> wrote:

> Carles Pina i Estany wrote:
> > Hello,
> >
> > I have to go to sleep now, but I've realized about a mistake or at
> > least unexpected behaviour.
> ...
> Looks like the mess is actually more profound than you describe.
> You
> replaced our mainstream with your branch. Looks like bzr failed at its
> primary task: protect against unintentional or intentional  deletion
> of files.  We should think of a way to make trunks and experimental
> branch commit-only. Meanwhile nobody pushes until further notice.
> I'll see how it can be recovered and protected.
> Robert: What is your latest backup before this accidental replacement?

The ‘append_revisions_only’ option should probably be set for all
public branches to prevent accidental non-commit changes (i.e.,
pushing that would reorder revisions, since ‘push’ is really a
mirroring operation and can change revision numbers for existing
revisions).  Add ‘append_revisions_only = True’ to the
branch's .bzr/branch/branch.conf (or, for new branches, use the
--append-revisions-only option when creating the branch with bzr init).
See
<http://doc.bazaar-vcs.org/bzr.2.0/en/user-reference/#append-revisions-only>
 for details.

When append_revisions_only is set, pushing to trunk can be done, but
it won't alter existing revisions, so it will prevent problems.  You
can't use the 'uncommit' command then, of course, but that is by
design.  To revert a revision (e.g., revno 44) you would use 
'bzr merge -r 44..43 ; bzr commit' instead, as this is an appending
operation only.

Obviously a malicious user can corrupt the repository since the
SSH/SFTP transport we're using allows full raw file access for
committers, but it's the accidental mess-ups we are really concerning
ourselves with since we have to trust committers anyway--hopefully we
have frequent automated backups.  (It might be worthwhile looking into
using revision signing at some point though as well as an extra measure
of security; I haven't used Bazaar's revision signing yet.)

Regards,
Colin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [URGENT] Re: bazaar

[Robert Millan]

On Tue, Nov 24, 2009 at 07:50:29AM -0800, Colin D Bennett wrote:
> 
> The ‘append_revisions_only’ option should probably be set for all
> public branches to prevent accidental non-commit changes

I didn't mention this back then, but append_revisions_only is in effect
for most branches now.  It's not automatically enabled for new branches,
but at least for the important ones like trunk and experimental already
have it.

This also implies that "uncommit" won't work anymore on already pushed
changes.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi