conflict if a dir is created in an udd branch

[Didier Roche-Tolomelli]

see https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/opendrim-lmp-powermanagement/oneiric-201107070710/+merge/67122

The patch and content is in the source package. The thing is, as it was the first patch, the debian/patches directory was created in both branches, and so the id doesn't match, hence the conflict. Any idea how to detect (making a traditional diff first?) and not make the autoimporter conflicting?

[Didier Roche-Tolomelli (didrocks)]

See as well:
https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/opendrim-lmp-bios/oneiric-201107070710/+merge/67121
https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/opendrim-lmp-softwareinventory/oneiric-201107070710/+merge/67120

[Stefano Rivera (stefanor)]

I sponsored some of the uploads causing those, and did bzr merges (with
sponsor-patch) when I uploaded them.

I'm not sure if the directories were the only issue. They don't have the
new quilt patch applied.
The last of those I did, opendrim-lmp-systemmemory, I applied quilt
patches to and bzr added everything in .pc. It still conflicted,
presumable because of the directory creation you mention.

[James Westby (james-w)]

The changes for systemmemory were apparently

('quilt_series-20110707091128-xwvi60u23l7rgg95-3', (u'.pc/.quilt_series', None), True, (True, False), ('pc-20110707091128-xwvi60u23l7rgg95-1', None), (u'.quilt_series', None), ('file', None), (False, None))
('timestamp-20110707091128-xwvi60u23l7rgg95-7', (u'.pc/01-ftbfs-add-opendrim-lib.patch/.timestamp', None), True, (True, False), ('01ftbfsaddopendrimli-20110707091128-xwvi60u23l7rgg95-5', None), (u'.timestamp', None), ('file', None), (False, None))
('quilt_patches-20110707091128-xwvi60u23l7rgg95-2', (u'.pc/.quilt_patches', None), True, (True, False), ('pc-20110707091128-xwvi60u23l7rgg95-1', None), (u'.quilt_patches', None), ('file', None), (False, None))

[James Westby (james-w)]

I think this is actually "nobody understands how to deal with quilt+bzr and never get it the way the importer
wants it so it re-does their changes"

There's also an issue in that it causes those conflicting ids. I think that means it should append the collision
tree to the list of trees to take the ids from when doing the re-import. This would make it a little easier
to read the diffs.

It's confusing that the diff you see on the merge proposal isn't the diff that caused it to appear. It would
be great to put the diff between the two tips on the merge proposal page too.

Thanks,

James

[Martin Pitt (pitti)]

As a side question, is all that trouble with having applied patches in bzr really worth it? I never got it right myself, it makes you want to pull your hair out, it's against common practice, makes commit diffs ugly to read, breaks merge-upstream, etc.

Can we just switch UDD to having non-applied patches perhaps?

[James Westby (james-w)]

On Thu, 07 Jul 2011 19:15:39 -0000, Martin Pitt <email address hidden> wrote:
> As a side question, is all that trouble with having applied patches in
> bzr really worth it? I never got it right myself, it makes you want to
> pull your hair out, it's against common practice, makes commit diffs
> ugly to read, breaks merge-upstream, etc.
>
> Can we just switch UDD to having non-applied patches perhaps?

We could. My justification for doing it was:

  * Debian is going through a multi-year effort to have patches-applied
    when a source package is unpacked. I agree with that and want it to
    be the default state for UDD

  * There wasn't a good way to do it without storing the patches-applied
    state in the revision.

Obviously the second isn't a good reason, just an implementation
shortfall.

I would advocate for fixing that rather than regressing to
patches-unapplied, and certainly would recommend against
patches-unapplied without an idea of how it could be transititioned back
to the better state.

It may be that for the sake of user's enjoyment that is the change that
should be made in the short term though.

I don't have the time to drive this forward at this stage. I hope that
someone from the Bazaar team can do that.

Thanks,

James

[Martin Pool (mbp)]

On 12 July 2011 07:32, James Westby <email address hidden> wrote:
> On Thu, 07 Jul 2011 19:15:39 -0000, Martin Pitt <email address hidden> wrote:
>> As a side question, is all that trouble with having applied patches in
>> bzr really worth it? I never got it right myself, it makes you want to
>> pull your hair out, it's against common practice, makes commit diffs
>> ugly to read, breaks merge-upstream, etc.
>>
>> Can we just switch UDD to having non-applied patches perhaps?
>
> We could. My justification for doing it was:
>
>  * Debian is going through a multi-year effort to have patches-applied
>    when a source package is unpacked. I agree with that and want it to
>    be the default state for UDD
>
>  * There wasn't a good way to do it without storing the patches-applied
>    state in the revision.
>
> Obviously the second isn't a good reason, just an implementation
> shortfall.
>
> I would advocate for fixing that rather than regressing to
> patches-unapplied, and certainly would recommend against
> patches-unapplied without an idea of how it could be transititioned back
> to the better state.
>
> It may be that for the sake of user's enjoyment that is the change that
> should be made in the short term though.
>
> I don't have the time to drive this forward at this stage. I hope that
> someone from the Bazaar team can do that.

For handling quilts, we are thinking of having the bzr client able to
unapply/reapply the patches, so we can resolve changes between each of
them on the way up. That would also give a chance to store the
unpatched source in the branch, but also have it patched-up by default
when people get a checkout, which would be broadly similar to what
apt-get source does. (I guess that policy would be done by
bzr-builddeb; there's policy a confusion failure mode there if people
get such a branch and don't have that plugin.)