headers
Matthieu Moy | 20 Aug 23:01
Picon
Picon
Favicon

Future of GNU Arch, bazaar and bazaar-ng ... ?

Hi all,

Recently, Tom announced hi was stopping the mainainance of GNU
Arch[1]. I didn't see an "official announcement", but as I understand
it, Canonical decided to move the effort from Bazaar to Bazaar-NG[2].
The wiki[3] now presents baz as "Bazaar 1" and bzr, AKA Bazaar-NG, as
"Bazaar 2".

This raises a few questions to me:

What's the future of tla 1.x? Same for 2.0. Given that the main
contributors of GNU Arch--except Tom--are mostly people working now on
Bazaar-NG, I _guess_ Bazaar is the way of the future.

What's the future of Bazaar (baz)? There was a roadmap here[4] that I
suppose is mostly outdated. In particular, I'd like to know if the
following plans have a chance to be implemented:

1) The namespace change (making a/c--b--v optional). If this makes its
   way into bazaar, I guess this will have an influence on front-ends
   in particular. Actually, I think this idea should be dropped given
   the new Bazaar<->Bazaar-NG situation.

2) The cached-inventory system. Since, as I understand it, Robert
   started working on this, and it could really improve the
   performance, that may be a good thing to get it in Bazaar.

Is there an approximate roadmap for Bazaar 2? Currently, Bazaar-NG is
evolving quickly, with no guarantee of backward compatibility, which
is good for a prototype, but will off course have to change. I think
(Continue reading)

Permalink | Reply | 121 comments |
headers
Thomas Lord | 16 Aug 03:46
Picon

GNU Arch maintainership


I would like to offer you (and respectfully (even if
publicly) ask that you accept) my resignation as GNU
Arch maintainer, effective immediately.

Here is my reasoning:

1. This is best for me.   The role will not help 
   me with my current troubles and those troubles
   prevent me from dedicating time to being a 
   GNU maintainer.

2. This would be best for the FSF since I can not
   represent the FSF's political stance on issues
   I think relevant to GNU Arch (and other GNU 
   projects).

I will remain a passive observer (and fan) of the FSF
and GNU.  In the future, if I have the opportunity
to, I may approach you about some completed software
projects I would like to offer for GNU.   (As you know,
my economic troubles are such that I am quite uncertain
I'll have such opportunity, but if I do I'd like to 
keep that door open.)

Perhaps, in that regard, your leadership of GNU has been
more mature and effective and aligned with the values
we've discussed recently than could be inferred from
my letters:  for quite some time now, you've endorsed
mostly projects which, for external reasons, stand a
(Continue reading)

Permalink | Reply | 8 comments |
headers
Thomas Lord | 5 Aug 21:04
Picon

important web site updates


I've made an important change (first link) to 

   http://www.gnuarch.org

and

   http://www.seyza.com

Thanks,
-t
Permalink | Reply | 0 comments |
headers
David Allouche | 2 Aug 19:32

Re: build-config, I need your opinion.

On Tue, 2005-08-02 at 02:13 -0400, Aaron Bentley wrote:
> David Allouche wrote:
> |       * When "not using greedy revlib and one of the two revisions used
> |         by apply-delta is not in the pristine cache" (might need to be
> |         adjusted, Aaron?)
> 
> It would be nicer to say:
> If the changeset is not already available because
> 1. Doing apply-delta DIRECT_ANCESTOR FOO is fairly common, but
> indistinguishable from replay

Not really, as apply-delta is a full-tree operation that requires
explicit DIRECT_ANCESTOR and FOO, while replay is a changeset operation
that only requires explicit delta(DIRECT_ANCESTOR, FOO).

> 2. It would be nice to cache every calculated delta, so we only had to
> calculate each one once.

That was not what I had in mind (and honestly, I find that in common
usage, most deltas are used only once, sometimes twice, but rarely
more).

> Is that the kind of thing you had in mind?

No, actually I meant "when the replay optimisation to update would be
used".

--

-- 
                                                            -- ddaa
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Lord | 1 Aug 18:45
Picon

[ANNOUNCE] Arch 2.0 release (revc.0.0x2)


A new release of Arch 2.0, revc,0.0x2, is now available.

        <http://www.seyza.com/releases/revc.0.0x2.tar.gz>

        /SHA1:/ `975ca3e74f44854b869d84d04425df06c1d94326'

        /MD5:/ `4ad474cb97f87baee19b1f40c49c0591'

        /Size:/ `1771820'

See http://www.seyza.com/revc for more information.

This release fixes some bugs reported regarding Cygwin (the ",es.exe"
bug and the "Cygwin pipes mangle line endings" bug -- both in the
build process).

This release a new, nicer archive format.   Revc archives are now
suitable for double-duty as revision control archives and general
purpose project FTP sites containing other files (such as release
tar bundles).

Revc is currently self-hosting -- I'll be making my archive available
for download by rsync shortly (I'll post a separate announcement).

-t
Permalink | Reply | 11 comments |
headers
Thomas Lord | 26 Jul 21:30
Picon

2.0, history, and merging (was Re: [Gnu-arch-users] arch 2.0 and delta compression)


Leaving aside the burning questions of whether the
"codeville merge algorithm" is desirable and, for
that matter, exactly what it is ...

I'll try here to briefly fill in developers on 
what's in revc re ancestry-for-merging tracking.

This is a good point in time, btw, to influence
the final design before it is locked down.

Here are things you need to know about ancestry in
revc, starting with some background:

* no more {arch}

  Revc does away entirely with the `{arch}' mechanism.
  It has no "in-tree" meta-data whatsoever.

  Revc *does* create a `.revc' directory at the root
  of a checked out tree but (a) it does not contain
  a patch log and (b) it is not a "regular directory" --
  it is not part of the inventory of the tree;  it is
  not ever blindly modified by merge algorithms; etc.

  The complete ancestry of a tree (see below) is available
  locally, in the .revc dir.   The complete ancestry of
  a tree can be retrieved from its commit record in "O(1)"
  which means that you can obtain it by opening a file
  and decompressing its contents.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthieu Moy | 26 Jul 18:57
Picon
Picon
Favicon

file-based history commands

Hi all,

We've discussed some time ago about the ability to see which revision
modified a particular file.

I'm hacking on this for baz at the moment. The
file-based-history-aware "logs" command is more or less operational.

Here's a demo (the file used to be scp-global.h and is now
pinapa-global.h):

$ baz logs -s -- include/scp-global.h
patch-12
    Use of namespaces in pinapa
patch-32
    Renamed pinapa source files (scp -> pinapa)
patch-33
    Renamed all macros and autoconf variables prefixed by SCP
patch-34
    Updated Copyrights in headers (use LGPL)

(=> works fine if you specify the original name)

$ baz logs -s -- include/pinapa-global.h                                                                                                                                          
patch-32
    Renamed pinapa source files (scp -> pinapa)
patch-33
    Renamed all macros and autoconf variables prefixed by SCP
patch-34
    Updated Copyrights in headers (use LGPL)
(Continue reading)

Permalink | Reply | 1 comment |
headers
John A Meinel | 26 Jul 00:58

[BAZ] build on Mac 10.4 fails with -Werror

Mac 10.4 uses a version of gcc4. Which means that it is more strict
about unsigned versus signed for string literals. Which means that it
gives a warning on all of the
int function(t_uchar *);

function("my string");

Because t_uchar is unsigned, and "my string" is a regular "char const
*", which is considered to be signed.

For now, I'm just compiling without -Werror. But is there a different fix?

I know Robert Collins once mentioned (probably in a commit message) that
he uses different flags than those listed at
http://wiki.gnuarch.org/BazaarCodingGuidelines

So maybe he could update that page with the new flags to use.

John
=:->
Permalink | Reply | 1 comment |
headers
John A Meinel | 26 Jul 00:13

[BAZ][BUG] Incomplete ancestry mirror messes up "baz get"

I have an incomplete mirror of robert.collins <at> canonical.com--general,
and a complete mirror of thelove <at> canonical.com.
I went to get a checkout of baz-1.5 (using baz-1.3.2), and it failed
mid-way while trying to get cexcept.
I assume the problem is that the robert.collins tree was 'tagged' into
the thelove <at> canonical.com one, and baz was trying to search the
ancestry, found that it could access the archive, but not the category,
and failed.

The desirable thing is for the revision builder to just treat a failed
access as 'not accessible' and build from what it knows.

This was done without a revision library, on Mac OS X. I cannot test it
with the latest baz, because I had to update my mirrors in order to do
the checkout.

John
=:->
Permalink | Reply | 0 comments |
headers
John A Meinel | 25 Jul 23:01

[BAZ] lock-revision without parameters

Even though baz tried to get it right, and watch out for failing
signatures to unlock the tree, I have found that if I ^C while gpg is
waiting, baz fails to unlock the tree. (I'm guessing the ^C is hitting
baz as well as gpg, but I'm not sure).

Anyway, I find myself using baz lock-revision -b fairly often. Baz did
the right thing in allowing you to supply a version instead of a
complete revision. I'm just asking for them to take the next step, such
that if nothing is supplied, it defaults to the current tree version.

Does this make sense, or is it better to require an option to lock-revision?

John
=:->
Permalink | Reply | 2 comments |
headers
Matthieu Moy | 20 Jul 11:35
Picon
Picon
Favicon

[BUG] Neon 2.5 breaks at least bazaar.

register-archive does a

              t_uchar * temp_location = escape_location (archive_name);

which itself does

t_uchar *
escape_location (t_uchar const *location)
{
    return ne_path_escape(location);
}

which on libneon 2.5 seems to transform "http://server.com" into
"/current/working/dir/http:/server.com".

Well, at least, a friend of mine had this strange behavior on MacOS
10.4.2, and downgrading to libneon 2.4 solved the problem.

--

-- 
Matthieu
Permalink | Reply | 2 comments |

Gmane