dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 17/06/11 23:26, Anders Logg wrote:
> Let me add to this that I don't think the removed revisions are a very
> big problem. I think it's cleaner without them, but it's a fairly
> small issue.
> 
> But what I don't like are the false claims that it doesn't work to use
> a normal bzr workflow (which it obviously does) and that it's a big
> hassle to make it work (which it certainly isn't).
> 
> Perhaps we can make the following compromise:
> 
> 0. Admit that I'm right (it works and it's not a hassle)
> 
> 1. Skip append_revisions_only for now
> 
> 2. Try to avoid removed revisions
> 
> 3. Maybe add back append_revisions_only at some point in the future
> when everyone has learned to do (2).
> 
> Will that work?
> 
> Point (0) is of particular importance. ;-)
> 

I'll concede (0) to you if we agree on (2) ;).

Garth

> --
> Anders
> 
> 
> On Fri, Jun 17, 2011 at 11:21:34PM +0200, Anders Logg wrote:
>> On Fri, Jun 17, 2011 at 10:57:15PM +0200, Martin Sandve Alnæs wrote:
>>>>> So your argument is that you should be able to push merges that will
>>>>> lead to removed revisions
>>>>
>>>> I don't see how this discussion can go anywhere if you insist that
>>>> revisions are being removed, which sounds drastic.
>>
>> That's what both Launchpad and the bzr manual are claiming.
>>
>>>> How can there be a merge to push if there has been no merge?
>>
>> There can have been as many merges as you want downstream, as in back
>> and forth between your local repositories, your personal repository at
>> Launchpad and from lp:dolfin into any of your repositories.
>>
>> Then what I'm asking is not to push those merges directly to
>> lp:dolfin, but instead merge all of that mess into lp:dolfin.
>>
>>> I have two points to add, then I'm out of here.
>>> I say this because I think it is valuable that
>>> everybody knows how to use the tools effectively,
>>> not because I care if you want to do it otherwise.
>>> I'm fine with Garths suggestion to just do our best.
>>>
>>>
>>> First, you can _always_ merge into lp:dolfin the "right" direction. Always.
>>> If you first merge the "wrong" direction:
>>>   cd mybranch && bzr merge lp:dolfin && bzr commit
>>> then you can always:
>>>   cd ../trunk # assuming no local additions over lp:dolfin here
>>>   bzr up  OR  bzr pull  # checkout or unbound branch
>>>   bzr merge ../mybranch && bzr commit
>>>   bzr push # only if trunk is unbound branch (automatic for a checkout)
>>
>> This is what I suggest (modulo the last push, see below).
>>
>>> Second, I just want to repeat this again (for the third time in this thread),
>>> because both "sides" of the discussion seem to get it wrong:
>>>
>>> The use of a checkout of trunk vs an unbound branch of trunk
>>> has no relation whatsever to the direction of the merge in your
>>> workflow. These are two orthogonal workflow choices.
>>
>> Thanks, I didn't know that.
>>
>> Anyway, my point remains: we shouldn't push merges made into other
>> repositories to lp:dolfin. That repository should remain clean.
>>
>> And let me repeat: it's not a hassle. The same number of commands as
>> usual (one less if using a bound trunk), just a different order in
>> another directory.
>>