dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

On 12/03/2012 10:32 AM, Anders Logg wrote:
> On Mon, Dec 03, 2012 at 09:22:55AM +0000, Garth N. Wells wrote:
>> On Mon, Dec 3, 2012 at 9:14 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>>> On Mon, Dec 03, 2012 at 10:08:00AM +0100, Johan Hake wrote:
>>>> In principle I do not have any objections. Also if you mess up your
>>>> commands it is fairly simple to just branch a new lp:dolfin and merge
>>>> from that, before it is pushed back.
>>>
>>> The problem is that the thing I messed up was the push to
>>> trunk. So there was no need or any opportunity to branch a new
>>> lp:dolfin. The damage was already done.
>>>
>>
>> Branching a new lp:dolfin is a problem on slow connections.

Not necessary. If you are using a shared repository for all your dolfin
branches:

  http://wiki.bazaar.canonical.com/SharedRepositoryTutorial

it can be very fast, also on slow Internet connections.

Johan

>>>> However, I see this mainly as a big short coming of bzr and/or buildbot.
>>>> Comparing if one revision is newer than another one in a distributed
>>>> version control system should be a solved problem...
>>>
>>> It's a solved problem if we set that flag.
>>
>> So the buildbot determines an individual developer's work flow?
> 
> Yes, as long as there's no simple fix for the buildbot.
> 
> I don't really care about the numbering issue anymore, as long as it
> works. Right now, it seems that doing `cd trunk && bzr merge ../dev`
> instead of `cd dev && bzr merge ../trunk && bzr push trunk` is an
> easier fix than figuring out how to get the buildbot (or bzr?) to use
> timestamps instead of changeset numbers.
> 
> --
> Anders
>