| 2010-06-10 10:11:16 |
Didier Roche-Tolomelli |
description |
The scenario seems to be the following (taking HACKING file as a filename example):
have a branch A (containing a HACKING file),
create a branch A-packaging from A (containing a HACKING file too, consequentely)
then, use merge-upstream workflow, the A pristine tar not having a HACKING file., HACKING file is so removed from A-packaging.
If upstream changed the HACKING file, and merge back the packaging branch to their upstream branch (for instance, with hudson daily build), there will be a conflict in the HACKING file. |
typical case:
- you have your upstream branch with a "foo" file
- this file isn't distributed into your tarball, so, at first merge-upstream, it will removing it from your packaging branch
- then, with the recipe, on the merge back, no issue (deleted)
… until the day, upstream change the content of "foo" file
change in "foo" in trunk + merge of a deleted file from the packaging branch -> FAIL
-------------
The scenario seems to be the following (taking HACKING file as a filename example):
have a branch A (containing a HACKING file),
create a branch A-packaging from A (containing a HACKING file too, consequentely)
then, use merge-upstream workflow, the A pristine tar not having a HACKING file., HACKING file is so removed from A-packaging.
If upstream changed the HACKING file, and merge back the packaging branch to their upstream branch (for instance, with hudson daily build), there will be a conflict in the HACKING file.
|
|
| 2010-06-29 07:20:54 |
Didier Roche-Tolomelli |
description |
typical case:
- you have your upstream branch with a "foo" file
- this file isn't distributed into your tarball, so, at first merge-upstream, it will removing it from your packaging branch
- then, with the recipe, on the merge back, no issue (deleted)
… until the day, upstream change the content of "foo" file
change in "foo" in trunk + merge of a deleted file from the packaging branch -> FAIL
-------------
The scenario seems to be the following (taking HACKING file as a filename example):
have a branch A (containing a HACKING file),
create a branch A-packaging from A (containing a HACKING file too, consequentely)
then, use merge-upstream workflow, the A pristine tar not having a HACKING file., HACKING file is so removed from A-packaging.
If upstream changed the HACKING file, and merge back the packaging branch to their upstream branch (for instance, with hudson daily build), there will be a conflict in the HACKING file.
|
typical case:
- you have your upstream branch with a "foo" file
- this file isn't distributed into your tarball, so, at first merge-upstream, it will removing it from your packaging branch
- then, with the recipe, on the merge back, no issue (deleted)
… until the day, upstream change the content of "foo" file
change in "foo" in trunk + merge of a deleted file from the packaging branch -> FAIL
-> upstream has to include all kind of crude packages like autogen.sh, .bzrignore to tarball. When we miss one, conflict occurs in hudson.
dx and desktop team loose approx one to two hours a week because of that, figuring out which files aren't distributed, relaunching hudson build and so on.
-------------
The scenario seems to be the following (taking HACKING file as a filename example):
have a branch A (containing a HACKING file),
create a branch A-packaging from A (containing a HACKING file too, consequentely)
then, use merge-upstream workflow, the A pristine tar not having a HACKING file., HACKING file is so removed from A-packaging.
If upstream changed the HACKING file, and merge back the packaging branch to their upstream branch (for instance, with hudson daily build), there will be a conflict in the HACKING file.
|
|
