[PATCH] Rename lxbios to nvramtool

[Uwe Hermann]

See patch.

This is step 1 in a three-step commit:

1. Apply patch, commit.

2. Rename some files:
    $ svn mv lxbios.c nvramtool.c
    $ svn mv lxbios.1 nvramtool.c
    $ svn mv lxbios.spec nvramtool.spec
    $ svn ci

3. Rename lxbios directory:
    $ svn mv lxbios/ nvramtool/
    $ svn ci

If I get an ACK for the patch, I'll do steps 2 and 3 also, right after
comitting the patch.

Additionally, the wiki page http://www.coreboot.org/Lxbios
will then be moved to http://www.coreboot.org/nvramtool.

Uwe.

[Patrick Georgi]

Am Freitag, den 25.01.2008, 16:37 +0100 schrieb Uwe Hermann:
> If I get an ACK for the patch, I'll do steps 2 and 3 also, right after
> comitting the patch.

How does that interact with those "symbolic links" in the cbv2 and cbv3
trees?

Regards,
Patrick Georgi

[Uwe Hermann]

On Fri, Jan 25, 2008 at 04:41:31PM +0100, Patrick Georgi wrote:
> Am Freitag, den 25.01.2008, 16:37 +0100 schrieb Uwe Hermann:
> > If I get an ACK for the patch, I'll do steps 2 and 3 also, right after
> > comitting the patch.
>
> How does that interact with those "symbolic links" in the cbv2 and cbv3
> trees?

Yep, those will need an update, too.

Uwe.

[Carl-Daniel Hailfinger]

We need to rethink this whole source tree renaming business. It
- messes up svn blame
- causes lots of breakage when you try to go back to versions before the
rename (try it with coreboot v2!)
- introduces inconsistencies in at least half of the patches (some
references to LB are changed, some remain)
- tries to purge all references to the previous name
- messes with local changes in some of the cases.

Sorry Uwe, this is not against you. I have been working with the trees a
lot in the past two weeks and the v2 rename has broken "svn up" to older
versions, svn blame gets interesting etc. Right now I'm working with
multiple trees, some in a state before the rename, some after the rename
and tracking down when some problems were introduced requires me to
switch trees constantly. That makes me really grumpy. If I could go back
in time, I'd stop the whole tree moving/renaming. Project renaming is
OK, but tree renaming is a real pain.

On 25.01.2008 16:37, Uwe Hermann wrote:
> See patch.
>
> This is step 1 in a three-step commit:
>
> Apply patch, commit.
>
> Rename some files:
> $ svn mv lxbios.c nvramtool.c
> $ svn mv lxbios.1 nvramtool.c
> $ svn mv lxbios.spec nvramtool.spec
> $ svn ci
>
> Rename lxbios directory:
> $ svn mv lxbios/ nvramtool/
> $ svn ci
>
> If I get an ACK for the patch, I'll do steps 2 and 3 also, right after
> comitting the patch.
>
> Additionally, the wiki page http://www.coreboot.org/Lxbios
> will then be moved to http://www.coreboot.org/nvramtool.
> Index: lxbios.c
>
> --- lxbios.c	(Revision 3075)
> +++ lxbios.c	(Arbeitskopie)
> @@ -1,5 +1,5 @@
>  /*****************************************************************************\
> lxbios.c
> nvramtool.c
> $Id$
> Copyright (C) 2002-2005 The Regents of the University of California.
>
> @@ -8,9 +8,9 @@
> UCRL-CODE-2003-012
> All rights reserved.
> This file is part of lxbios, a utility for reading/writing coreboot
> This file is part of nvramtool, a utility for reading/writing coreboot
> parameters and displaying information from the coreboot table.
> For details, see http://coreboot.org/Lxbios.
> For details, see http://coreboot.org/nvramtool.

NACK. Either remove the terminating full stop or separate it from the
URL with a space.
> Please also read the file DISCLAIMER which is included in this software
> distribution.
> Index: lbtable.c
>
> --- lbtable.c	(Revision 3075)
> +++ lbtable.c	(Arbeitskopie)
> @@ -9,9 +9,9 @@
> UCRL-CODE-2003-012
> All rights reserved.
> This file is part of lxbios, a utility for reading/writing coreboot
> This file is part of nvramtool, a utility for reading/writing coreboot
> parameters and displaying information from the coreboot table.
> For details, see http://coreboot.org/Lxbios.
> For details, see http://coreboot.org/nvramtool.

Same here.
> Please also read the file DISCLAIMER which is included in this software
> distribution.
> Index: lbtable.h
>
> --- lbtable.h	(Revision 3075)
> +++ lbtable.h	(Arbeitskopie)
> @@ -8,9 +8,9 @@
> UCRL-CODE-2003-012
> All rights reserved.
> This file is part of lxbios, a utility for reading/writing coreboot
> This file is part of nvramtool, a utility for reading/writing coreboot
> parameters and displaying information from the coreboot table.
> For details, see http://coreboot.org/Lxbios.
> For details, see http://coreboot.org/nvramtool.

Same here.
> Please also read the file DISCLAIMER which is included in this software
> distribution.
>
> @@ -29,8 +29,8 @@
> 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
>
> *****************************************************************************/
>
> -#ifndef LXBIOS_LBTABLE_H
> -#define LXBIOS_LBTABLE_H
> +#ifndef LBTABLE_H
> +#define LBTABLE_H

Now that does not make sense. Why LBtable?
> #include "common.h"

Regards,
Carl-Daniel

[Stefan Reinauer]

* Uwe Hermann  [080125 16:37]:
> See patch.
>
> This is step 1 in a three-step commit:
>
> Apply patch, commit.
>
> Rename some files:
> $ svn mv lxbios.c nvramtool.c
> $ svn mv lxbios.1 nvramtool.c
> $ svn mv lxbios.spec nvramtool.spec
> $ svn ci
>
> Rename lxbios directory:
> $ svn mv lxbios/ nvramtool/
> $ svn ci
>
> If I get an ACK for the patch, I'll do steps 2 and 3 also, right after
> comitting the patch.
>
> Additionally, the wiki page http://www.coreboot.org/Lxbios
> will then be moved to http://www.coreboot.org/nvramtool.
> Uwe.
>
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
> Rename lxbios to nvramtool.
>
> Signed-off-by: Uwe Hermann

I agree with CDH that we need to be careful with what we rename, but
this is the one thing that directly exposes all of coreboot to the user.
And some of the payloads, too. So even before lxbios was a
not-so-fitting name. Let's do it.

Acked-by: Stefan Reinauer

[Stefan Reinauer]

* Carl-Daniel Hailfinger  [080126 01:50]:
> causes lots of breakage when you try to go back to versions before the
>
> rename (try it with coreboot v2!)

Tried it, worked fine for all renamed files and directories. Are you
confusing this with CVS, maybe?  I suggest http://svnbook.red-bean.com/
for all people with problems regarding the repository.
> introduces inconsistencies in at least half of the patches (some
>
> references to LB are changed, some remain)

What you call inconsistencies was done on purpose. Renaming the LB_
defines used for the coreboot table would break all payloads using that
information out there. That's a no-go.

Like any other open source project, coreboot is a living project that is
being worked on. The fact that changes happen gradually and
incrementally is nothing inconsistent. We did not break any boards with
them either. It seems you are not content with the way we renamed the
project, but your hints are kind of vague. Those that we could read
between the lines were taken into regard (I hope). Please help us get
the rest fixed.
> Sorry Uwe, this is not against you. I have been working with the trees a
> lot in the past two weeks and the v2 rename has broken "svn up" to older
> versions, svn blame gets interesting etc. Right now I'm working with
> multiple trees, some in a state before the rename, some after the rename
> and tracking down when some problems were introduced requires me to
> switch trees constantly. That makes me really grumpy. If I could go back
> in time, I'd stop the whole tree moving/renaming. Project renaming is
> OK, but tree renaming is a real pain.

Try following the hints I sent to the list on how to upgrade the tree.
These helped me migrate over a dozen trees in different states with
nearly no conflicts. It's really trivial in most cases.

Stefan

[Carl-Daniel Hailfinger]

On 27.01.2008 01:53, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger  [080126 01:50]:
> > causes lots of breakage when you try to go back to versions before the
> >
> > rename (try it with coreboot v2!)
>
> Tried it, worked fine for all renamed files and directories. Are you
> confusing this with CVS, maybe?  I suggest http://svnbook.red-bean.com/
> for all people with problems regarding the repository.

I know that page very well and followed its instructions to the letter:
http://svnbook.red-bean.com/en/1.4/svn.tour.history.html#svn.tour.history.sn...
Just in case you don't believe me that it will not work for the v2 tree,
here are the steps to reproduce:

# svn co svn://coreboot.org/repos/trunk/coreboot-v2
[...]
Checked out revision 3084.
# cd coreboot-v2/
# svn up -r 3049
svn: Target path does not exist
# svn --version
svn, Version 1.4.4 (r25188)

Full typescript attached.

Can anybody show me a typescript where going back to revision 3049
works? Please also include the version of svn you used.

Regards,
Carl-Daniel

[Corey Osgood]

Carl-Daniel Hailfinger wrote:
> On 27.01.2008 01:53, Stefan Reinauer wrote:
> > Carl-Daniel Hailfinger  [080126 01:50]:
> > > causes lots of breakage when you try to go back to versions before the
> > >
> > > rename (try it with coreboot v2!)
> >
> > Tried it, worked fine for all renamed files and directories. Are you
> > confusing this with CVS, maybe?  I suggest http://svnbook.red-bean.com/
> > for all people with problems regarding the repository.
>
> I know that page very well and followed its instructions to the letter:
> http://svnbook.red-bean.com/en/1.4/svn.tour.history.html#svn.tour.history.sn...
> Just in case you don't believe me that it will not work for the v2 tree,
> here are the steps to reproduce:
>
> # svn co svn://coreboot.org/repos/trunk/coreboot-v2
> [...]
> Checked out revision 3084.
> # cd coreboot-v2/
> # svn up -r 3049
> svn: Target path does not exist
> # svn --version
> svn, Version 1.4.4 (r25188)
>
> Full typescript attached.
>
> Can anybody show me a typescript where going back to revision 3049
> works? Please also include the version of svn you used.
>
> Regards,
> Carl-Daniel

Odd, I can confirm that doesn't work (exact same svn version, on debian 
lenny, ubuntu 7.10, and opensuse 10.3 x86_64), but doing svn diff -r 
3000 works fine. Looks like an svn bug.

-Corey

[Corey Osgood]

Corey Osgood wrote:
> Carl-Daniel Hailfinger wrote:
> > On 27.01.2008 01:53, Stefan Reinauer wrote:
> > > Carl-Daniel Hailfinger  [080126
> > >
> > > 01:50]:
> > > > causes lots of breakage when you try to go back to versions
> > > >
> > > > before the
> > > > rename (try it with coreboot v2!)
> > >
> > > Tried it, worked fine for all renamed files and directories. Are you
> > > confusing this with CVS, maybe?  I suggest http://svnbook.red-bean.com/
> > > for all people with problems regarding the repository.
> >
> > I know that page very well and followed its instructions to the letter:
> > http://svnbook.red-bean.com/en/1.4/svn.tour.history.html#svn.tour.history.sn...
> >
> > Just in case you don't believe me that it will not work for the v2 tree,
> > here are the steps to reproduce:
> >
> > # svn co svn://coreboot.org/repos/trunk/coreboot-v2
> > [...]
> > Checked out revision 3084.
> > # cd coreboot-v2/
> > # svn up -r 3049
> > svn: Target path does not exist
> > # svn --version
> > svn, Version 1.4.4 (r25188)
> >
> > Full typescript attached.
> >
> > Can anybody show me a typescript where going back to revision 3049
> > works? Please also include the version of svn you used.
> >
> > Regards,
> > Carl-Daniel
>
> Odd, I can confirm that doesn't work (exact same svn version, on 
> debian lenny, ubuntu 7.10, and opensuse 10.3 x86_64), but doing svn 
> diff -r 3000 works fine. Looks like an svn bug.
>
> -Corey

OTOH, svn co svn://coreboot.org/repos/trunk/coreboot-v2 -r 3000 works as 
expected, except that externals are the latest version.

-Corey

[Carl-Daniel Hailfinger]

On 28.01.2008 04:14, Corey Osgood wrote:
> Corey Osgood wrote:
> > Carl-Daniel Hailfinger wrote:
> > > On 27.01.2008 01:53, Stefan Reinauer wrote:
> > > > Carl-Daniel Hailfinger
> > > >
> > > > [080126 01:50]:
> > > > > causes lots of breakage when you try to go back to versions
> > > > >
> > > > > before the
> > > > > rename (try it with coreboot v2!)
> > > >
> > > > Tried it, worked fine for all renamed files and directories. Are you
> > > > confusing this with CVS, maybe?  I suggest
> > > > http://svnbook.red-bean.com/
> > > > for all people with problems regarding the repository.
> > >
> > > I know that page very well and followed its instructions to the letter:
> > > http://svnbook.red-bean.com/en/1.4/svn.tour.history.html#svn.tour.history.sn...
> > >
> > > Just in case you don't believe me that it will not work for the v2
> > > tree,
> > > here are the steps to reproduce:
> > >
> > > # svn co svn://coreboot.org/repos/trunk/coreboot-v2
> > > [...]
> > > Checked out revision 3084.
> > > # cd coreboot-v2/
> > > # svn up -r 3049
> > > svn: Target path does not exist
> > > # svn --version
> > > svn, Version 1.4.4 (r25188)
> > >
> > > Full typescript attached.
> > >
> > > Can anybody show me a typescript where going back to revision 3049
> > > works? Please also include the version of svn you used.
> >
> > Odd, I can confirm that doesn't work (exact same svn version, on
> > debian lenny, ubuntu 7.10, and opensuse 10.3 x86_64), but doing svn
> > diff -r 3000 works fine. Looks like an svn bug.
>
> OTOH, svn co svn://coreboot.org/repos/trunk/coreboot-v2 -r 3000 works
> as expected, except that externals are the latest version.

Indeed. That's why I wrote that I have to keep multiple trees. One
checkout with the revision during checkout set to something before the
rename, the other checkout is current.

Regards,
Carl-Daniel

[Uwe Hermann]

On Sat, Jan 26, 2008 at 10:40:23PM +0100, Stefan Reinauer wrote:
> I agree with CDH that we need to be careful with what we rename, but
> this is the one thing that directly exposes all of coreboot to the user.
> And some of the payloads, too. So even before lxbios was a
> not-so-fitting name. Let's do it.
>
> Acked-by: Stefan Reinauer

Thanks, r3122 et al.

Uwe.

[Carl-Daniel Hailfinger]

On 01.03.2008 20:17, Uwe Hermann wrote:
> On Sat, Jan 26, 2008 at 10:40:23PM +0100, Stefan Reinauer wrote:
> > I agree with CDH that we need to be careful with what we rename, but
> > this is the one thing that directly exposes all of coreboot to the user.
> > And some of the payloads, too. So even before lxbios was a
> > not-so-fitting name. Let's do it.
> >
> > Acked-by: Stefan Reinauer
>
> Thanks, r3122 et al.

And it breaks when going back with "svn up" for any revision up to 626 
in v3.
Q.E.D.

compiler@p35:/sources/tmptrees/corebootv3-tmp3> svn up

Fetching external item into 'util/flashrom'
External at revision 3125.

Fetching external item into 'util/nvramtool'
External at revision 3125.

Fetching external item into 'util/superiotool'
External at revision 3125.

At revision 627.
compiler@p35:/sources/tmptrees/corebootv3-tmp3> svn up -r 626
 U   util

Fetching external item into 'util/flashrom'
Updated external to revision 3125.

Fetching external item into 'util/superiotool'
Updated external to revision 3125.

Fetching external item into 'util/lxbios'
svn: URL 'svn://linuxbios.org/repos/trunk/util/lxbios' doesn't exist

Regards,
Carl-Daniel

[Corey Osgood]

On Sat, Mar 1, 2008 at 2:36 PM, Carl-Daniel Hailfinger <
[e-mail]> wrote:
> On 01.03.2008 20:17, Uwe Hermann wrote:
> > On Sat, Jan 26, 2008 at 10:40:23PM +0100, Stefan Reinauer wrote:
> > > I agree with CDH that we need to be careful with what we rename, but
> > > this is the one thing that directly exposes all of coreboot to the
>
> user.
> > > And some of the payloads, too. So even before lxbios was a
> > > not-so-fitting name. Let's do it.
> > >
> > > Acked-by: Stefan Reinauer
> >
> > Thanks, r3122 et al.
>
> And it breaks when going back with "svn up" for any revision up to 626
> in v3.

does svn up --ignore-externals work?

-Corey

[Carl-Daniel Hailfinger]

On 01.03.2008 21:00, Corey Osgood wrote:
> On Sat, Mar 1, 2008 at 2:36 PM, Carl-Daniel Hailfinger <
> [e-mail]> wrote:
> > On 01.03.2008 20:17, Uwe Hermann wrote:
> > > On Sat, Jan 26, 2008 at 10:40:23PM +0100, Stefan Reinauer wrote:
> > > > I agree with CDH that we need to be careful with what we rename, but
> > > > this is the one thing that directly exposes all of coreboot to the
> >
> > user.
> > > > And some of the payloads, too. So even before lxbios was a
> > > > not-so-fitting name. Let's do it.
> > > >
> > > > Acked-by: Stefan Reinauer
> > >
> > > Thanks, r3122 et al.
> >
> > And it breaks when going back with "svn up" for any revision up to 626
> > in v3.
>
> does svn up --ignore-externals work?

Yes, it does. Thanks. Care to write something up in the wiki?

Regards,
Carl-Daniel