Re: [Gnu-arch-users] Conflicts in .arch-ids

[Tom Lord]

    > From: Catalin Marinas <address@hidden>

    > [....] What I don't know is how to best solve the conflicts in the
    > .arch-ids directory. [....]

    > I am using tla for Linux kernel development. I have 2 archives -
    > linux--mainline--2.6 which tracks to changes in the main kernel and
    > linux--cm--2.6 for my changes. For example, I develop a driver in
    > drivers/net/aaa.c and save the changes in my linux--cm--2.6 archive. I
    > also submit the patch to the main kernel developers but continue
    > developing the driver in my archive.

    > The linux--mainline--2.6 archive is updated by applying the patch
    > releases from kernel.org, run tla-udpate-ids and commit the
    > changes. When the kernel developers decide to include my driver into
    > their kernel I will get a drivers/net/aaa.c file and a
    > .arch-ids/aaa.c.id file in the linux--mainline--2.6 archive. The id
    > file will always be different and the aaa.c is also possible to be
    > different.

(I don't use tla-update-ids personally, but...) After running
tla-update-ids can't you "by hand" fix those few files?  I.e., replace
the .id files that were created with ones copied from your branch?

Sure, that could perhaps be automated a bit but, in the meanwhile, it
sounds like you have a fairly easy case to deal with by hand. 


    > After a "tla star-merge", the I get a conflict for both aaa.c and
    > aaa.c.id files. What's the best way to fix/avoid the conflict for the
    > id file? I am using the explicit id tagging method. Is this possible
    > with this tagging method or I have to switch to "names" (I would lose
    > the history when renaming files though)?

Brute force, one-time solution would be by-hand fix up the .id files
in the maniline branch.   If you've already committed here and there
since then, it make take you a few revisions before your back in a
comfortable state where star-merging works happily.

As a general problem, needing a general solution .... my original
thought (which I still think is a good idea but don't expect to catch
on) is to factor out the `inventory' mechanism from `tla', and also
factor out the `mkpatch/dopatch' functionality.   

With those factorizations: Linus could (perhaps) be convinced to add
inventory tags to the official tree and also to accept
`mkpatch'-generated changesets.  Gosh, maybe he could even be
convinced to press for a `dopatch'-oriented change history of the
kernel.

-t