<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://blog.gmane.org/gmane.comp.version-control.bazaar-ng.general">
    <title>gmane.comp.version-control.bazaar-ng.general</title>
    <link>http://blog.gmane.org/gmane.comp.version-control.bazaar-ng.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49753"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49740"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49739"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49738"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49728"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49719"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49716"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49708"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49704"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49700"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49696"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49691"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49688"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49678"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49677"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49674"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49668"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49661"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49656"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49653"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49753">
    <title>[MERGE] Fix #87179 by using the short status format when the shortformat is used for log.</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49753</link>
    <description>The fix is certainly simpler now than when the bug was reported.

Hence the almost trivial patch,

      Vincent

</description>
    <dc:creator>Vincent Ladeuil</dc:creator>
    <dc:date>2008-12-01T15:49:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49740">
    <title>One big project with multiple small projects</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49740</link>
    <description>Hello,

I'm starting one big project which consist of several independant modules
that will talk over D-BUS. I'm wondering how I can set a bzr repository for
it.

Some background :
- Each module will have a different maintener (even if a maintener can have
multiple module)
- Some modules are existing Open Source application that already use bzr for
their upstream development.
- There should be a central point which handle all the modules (like a shell
script that will start them all)
- The whole project should be easily installable on a freshly installed
computer (so we want to avoid a big howto which implies doing 17 bzr branch)

Solution that I see :

1) Having a big bzr repository that will handle the whole project
+ Easy to set up and to install on a new computer : bzr branch and you are
done
- Mainteners are maybe not interested in all other modules
- Upstream sync becomes  a nightmare. It means that we take an existing
project and put it in our own VCS which I want to avoid at all costs.

2) Having a b</description>
    <dc:creator>Lionel Dricot</dc:creator>
    <dc:date>2008-12-01T14:34:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49739">
    <title>Equivalent to SVN lock</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49739</link>
    <description>Hello,

Here at work, we have a big binary file (shame on us, it's an Excel file)
that should be regularly updated by some people.

This file is on a SVN repository and, in order to avoid conflict, we use svn
lock feature :
http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.lock.html

The workflow is then :

svn update
svn lock xls file
update the file
svn commit
svn unlock


Is there any equivalent in Bzr (I didn't found one) or any workflow that
would allow us to edit the file ?

Thanks in advance,

Lionel
</description>
    <dc:creator>Lionel Dricot</dc:creator>
    <dc:date>2008-12-01T14:23:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49738">
    <title>Reusing or delete branch name/path in a central repository</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49738</link>
    <description>
Hi!

There does not seam to be a way to delete a branch from a central repository
using Bazaar commands, e.g. “bzr branch –delete &lt;path&gt;”. Is there a known
workaround for this without providing access to the actual file system where
the Bazaar repository is stored?

I guess there is a good reasons for not including the delete branch support,
and I would appreciate some comments regarding this issue, or if some one
can post a link or search phrase with more information. I have searched for
information and found this:
  
https://bugs.launchpad.net/bugs/276295


I imagine two uses for deleting branches:

1) After a branch has been merged into the parent, there is often little use
of keeping the branch, especially after some time when the project has moved
forward. 

2) It would make it possible to reuse branch names/paths. E.g. the second
time that someone wants to implement a specific feature.


On a local file system (distributed work flow) this is of course no problem,
but when working with a central </description>
    <dc:creator>Michael Reichenauer</dc:creator>
    <dc:date>2008-12-01T14:00:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49728">
    <title>[rfc] 'bzr reconfigure --stacked-on/--no-stacked'</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49728</link>
    <description>There is at present no user-accessible way to change a branch between
being stacked on another repository, and containing all its history in
its own repository.  I think there should be.  It would be useful in
general, and in particular as a workaround if people are having
trouble with stacking on Launchpad, which suggests that setting for
some projects.  Basically this is just to expose the
Branch.set_stacked_on() call.

I think this belongs in 'reconfigure'; it shouldn't be invoked often
enough to need its own command.

</description>
    <dc:creator>Martin Pool</dc:creator>
    <dc:date>2008-12-01T07:04:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49719">
    <title>thread names in urls (Re: Creating a branch other than master usingbzr-git)</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49719</link>
    <description>On Wed, Nov 26, 2008 at 3:41 AM, John Arbash Meinel
&lt;john&lt; at &gt;arbash-meinel.com&gt; wrote:

That would be good. bzr-git needs something like this, and it is a bit
limiting that thread names are only distinguished by occurring in
particular arguments or options.

I think using ? and # is problematic because they're both shell
metacharacters, and it would be tedious to always explain to someone
why they typed the location in and had everything after the # ignored,
or got a 'no matches' error when they used ?.  You could say 'just
always escape it' but then the escaping will be different between Unix
and Windows.  Also, the fragment is not sent to the server by browsers
</description>
    <dc:creator>Martin Pool</dc:creator>
    <dc:date>2008-12-01T06:14:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49716">
    <title>RFC: commit-to-branch</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49716</link>
    <description>I'd like some feedback on UI for committing to a different branch.

Firstly the use case - in a loom one often prepares work that belongs on
a different lower thread[branch].

The slow way is:
bzr switch actual-thread
bzr commit files-to-commit
bzr shelve --all
while not-on-the-original-thread up;bzr commit
bzr unshelve --all

I'd like this to be a single command for convenience.

I think overloading commit is best because this can be used for normal
bzr branches too (or the recently announced many-branches-colocated
plugin too).

So splitting this up there are several different things needed:
 - loom needs to be able to intercept the 'update the working tree' step
   and have it do the 'up-commit-repeat' dance in the background, then
   give control back, with a new local revision id.
 - commit needs an option to tell it to commit to a different branch
   object, and when doing that commit it wants to apply a delta based on
   the current tree rather than supplying full texts.
 - loom needs to make sure tha</description>
    <dc:creator>Robert Collins</dc:creator>
    <dc:date>2008-12-01T04:29:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49708">
    <title>[merge][#165014] url parser accepts IPv6 literals</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49708</link>
    <description>Here's a cleanup of the patch attached to this bug.  It doesn't
completely fix it as there's still a problem in actually creating a
socket to an ipv6 server.

I moved the code from Transport to being in urlutils which seems a
better place.

This method is a bit duplicative of the builtin python urlparse, but
it can't handle the case complained of in this bug.

</description>
    <dc:creator>Martin Pool</dc:creator>
    <dc:date>2008-12-01T03:45:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49704">
    <title>bzr version numbers</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49704</link>
    <description>I wonder if it would be good to start using dates as part of our
versions? I just commented on a bug reported using 1.5, and I couldn't
(offhand) remember when it was released...

-Rob
</description>
    <dc:creator>Robert Collins</dc:creator>
    <dc:date>2008-11-30T21:07:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49700">
    <title>[Merge][#301969]Give proper error message for diff with non-existentdotted revno</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49700</link>
    <description/>
    <dc:creator>Marius Kruger</dc:creator>
    <dc:date>2008-11-30T20:18:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49696">
    <title>BzrEclipse and CPU load</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49696</link>
    <description>Hi,

I've been using BzrEclipse for some several hours in train trip on a
laptop, and I've to say that it's not usable in this way.

Each time you make a right click on a file, you get some Full CPU load
for 5-10 seconds (power saving mode, CPU is weak)

and the worse, if you happen to modify a file in your project (why
should someone do that :op), it get full CPU load for one or 2
minutes.

So if you want to work on a laptop, you have to set your cpu speed to
max so that it do not take too much time or see your CPU suck your
battery during several minutes.


The same behaviour exist on a regular computer but less noticable (but
still... it slow down things).


So... BzrEclipse compared to CVS is damn slow (yes... crazy isn't it ?)

I've the impression that each time you modify a file, it rescan the
whole project (why would it take so long and so much CPU)

I've setup my project on launchpad, but I'm seriously considering to
revert back to CVS for this performance reason.

There's many eclipse developer arou</description>
    <dc:creator>Thomas Manson</dc:creator>
    <dc:date>2008-11-29T23:51:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49691">
    <title>Bazaar meld plugin</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49691</link>
    <description>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Meld diftool (http://meld.sf.net) includes an enhanced vcs differ which
also supports bzr. As they're both written in python I think it would ve
easy to write a plugin for meld to add a melddiff command. Would anyone
be interested in using, helping to develop and test such a plugin?

Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkxmO8ACgkQRh6X64ivZaI8IwCfQX02G2h8OaQF0H4qRf4nwxps
M+EAnAjcI8ZmpVc5DnFibCl7w2lkLUJv
=aoeT
-----END PGP SIGNATURE-----


</description>
    <dc:creator>Serkan Kaba</dc:creator>
    <dc:date>2008-11-29T19:33:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49688">
    <title>[MERGE] Support upgrading non-.bzr directories</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49688</link>
    <description/>
    <dc:creator>Jelmer Vernooij</dc:creator>
    <dc:date>2008-11-29T15:18:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49678">
    <title>[MERGE][#303206] Call PyErr_NoMemory() before returning NULL inPatienceSequenceMatcher_new.</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49678</link>
    <description>This one-liner hopefully fixes a SystemError in _patiencediff_c.  If a
malloc call in PatienceSequenceMatcher_new returned NULL, we were returning
NULL from PatienceSequenceMatcher_new without setting a Python exception,
thus the SystemError.  This patch calls PyErr_NoMemory before the return, to
cause a MemoryError instead.

This doesn't fix &lt;https://bugs.launchpad.net/bzr/+bug/303206&gt;, but hopefully
it will at least make it fail with an appropriate exception (and make it
possible to write code that catches the MemoryError and falls back to
something less memory hungry, perhaps just dumping THIS/OTHER files to
disk?)

-Andrew.

</description>
    <dc:creator>Andrew Bennetts</dc:creator>
    <dc:date>2008-11-29T00:36:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49677">
    <title>Group writable bzr+ssh</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49677</link>
    <description>Using the smart server through bzr+ssh, I'd like several users to be
able to collaborate on ad-hoc branches without manually setting
permissions or configuring special umasks. I've read in several places that
bzr can preserve the group permission from the repo, but this
isn't working for me on Ubuntu 8.04 with the dev ppa version of bazaar 1.9:

bzr --version
Bazaar (bzr) 1.9
  Python interpreter: /usr/bin/python 2.5.2
  Python standard library: /usr/lib/python2.5
  bzrlib: /usr/lib/python2.5/site-packages/bzrlib
  ...

My server based directory structure starts like this:

server/                                     #This is the repository
|-- [drwxrws--- bzruser  users]  .bzr
|      (snip)

From the client if I do:
bzr push  bzr+ssh://host/path/server/testing

I end up with the following:

server/
|-- [drwxrws--- bzruser  users]  .bzr
|       (snip)
|-- [drwxr-sr-x brad     users   ]  testing  #No group write perm
|   `-- [drwxr-sr-x brad     users   ]  .bzr
|           (snip)


Note that the permission on</description>
    <dc:creator>Brad Schick</dc:creator>
    <dc:date>2008-11-28T23:24:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49674">
    <title>Please help Python team decide on a VCS</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49674</link>
    <description>Howdy all,

The Python development team is currently drafting a PEP discussing the
move from Subversion to a modern VCS. The contenders are Bazaar,
Mercurial, and Git.

The PEP document is being drafted via Google Docs, and is currently at
&lt;URL:http://docs.google.com/View?docid=dg7fctr4_40dvjkdg64&gt;. Sadly I
can't see any way of contacting the authors; presumably the
‘python-dev’ mailing list would be appropriate.

Though Bazaar has made the cut for evaluation, it is currently the
least represented by information; most of the use cases have “fill in
this blank” markers waiting for actual information.

I would be delighted to see Bazaar chosen as the VCS for tracking
Python development; I hope someone can work with the relevant people
in the Python development team to improve this PEP with sufficient
information on Bazaar to make the informed choice.

</description>
    <dc:creator>Ben Finney</dc:creator>
    <dc:date>2008-11-28T21:24:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49668">
    <title>Is it possible to disable autopack?</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49668</link>
    <description>I'm doing file-based remote backups of a bazaar repository. The
revisions often have several megabytes. I want to disable autopacking
because the consolidation every 10 commits costs a lot of bandwith. Is
there a option to disable autopacking for a single repository?

I guess i could disable autopack for all repositories by adding a
"return False" in autopack in pack_repo.py?





</description>
    <dc:creator>Christian Tschabuschnig</dc:creator>
    <dc:date>2008-11-28T16:42:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49661">
    <title>bzr for documents</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49661</link>
    <description>I dont know if this is right use for bzr (or if this is a very basic
question :-)
I want to use bzr for text documents -- usually emacs-org files.

The usage scenario is

1. Files reside in a number of different directories
2. Many (one-off) documents may not be versioned
3. Their histories are usually unrelated
4. Documents that are versioned may have complex (branching) histories

So some (specific) questions:
</description>
    <dc:creator>Rustom Mody</dc:creator>
    <dc:date>2008-11-28T13:27:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49656">
    <title>bzr 1.10rc1 released for testing</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49656</link>
    <description>Hi,

I'm happy to announce availability of bzr 1.10rc1, and to ask for your
help in testing it.  Our goal is to make a final release of 1.10 later
this week.

Source is available now from &lt;https://launchpad.net/bzr/1.10/1.10rc1&gt;
and Ubuntu and other packages should be available soon.

The full changelog is below.  It makes sense to concentrate testing on
the things most changed in this release: shelve and unshelve,
fetching, and bzr+ssh operations.  If you find problems, please let us
know by filing a bug, or on irc or the list.

</description>
    <dc:creator>Martin Pool</dc:creator>
    <dc:date>2008-11-28T06:11:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49653">
    <title>[merge] notes on how to use bzr-builddeb to package bzr-svn</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49653</link>
    <description>I've just uploaded bzr-svn 0.4.15 to the beta ppa.  Here are some
notes on how to update it using bzr-builddeb; it's not rocket science
but it's sufficiently different from the other packages that having a
cheat sheet seems useful.

</description>
    <dc:creator>Martin Pool</dc:creator>
    <dc:date>2008-11-28T05:27:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49638">
    <title>Keeping local configuration versioned</title>
    <link>http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/49638</link>
    <description>Hi,

I'm looking for a solution to what I think is a fairly common problem: 
I'm working on a website, and obviously have a local branch. This branch, 
in addition to all the development I want to push upstream, has some 
changes related to the DB/host settings that I _don't_ want propagated 
into mainline, but which I'd nevertheless like to have versioned (the 
changed files are versioned in the mainline, so I sort of don't have a 
choice anyway). However, I can't see a branch structure/plugin/whatever 
that would let me have that.

I thought about just arranging multiple local branches carefully at 
first, but I couldn't find a setup that wouldn't result in either me 
having to sync things manually (not good) or having to remember about not 
committing things (obviously a no go). For a moment, it looked like loom 
might be the solution, but it turns out it's actually sort of opposite of 
what I want to achieve (it lets me hide history and the resulting changes 
on the fly, whereas I very much want to have </description>
    <dc:creator>Maciej Katafiasz</dc:creator>
    <dc:date>2008-11-27T12:27:55</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.comp.version-control.bazaar-ng.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.version-control.bazaar-ng.general</link>
  </textinput>
</rdf:RDF>
