Hi Bryce + devs,
I'm a bit worried about the Git migration. I'm a bit impatient ;-) but we haven't heard much from KK about availability and I'm thinking we need to plan a contingency.
Thoughts?
Are we planning to get this done at the hackfest?
Best Regards, Martin Owens
Am 31.05.2017 um 14:12 schrieb Martin Owens:
Hi Bryce + devs,
I'm a bit worried about the Git migration. I'm a bit impatient ;-) but we haven't heard much from KK about availability and I'm thinking we need to plan a contingency.
Thoughts?
Are we planning to get this done at the hackfest?
Best Regards, Martin Owens
Hi Martin,
I think Ted was looking into the git migration. Last time I talked to him on IRC it sounded as if he had it mostly figured out but there was still an issue with converting some old branches.
If some assistance is needed I might also be able to help out, as I played around a bit with the conversion myself (I was investigating if there was a nice way to preserve metatadata that bzr has but git does not, notably revision numbers, fixed bugs and multiple authors) and already did one full conversion of trunk plus some sample branches in the process.
Regarding hackfest: I don't attend, so it's probably not up to me to suggest anything, but from what I experienced such a migration is mostly waiting for the conversion to finish and uploading and I doubt it's much fun to do during a hackfest. Also I guess time is better spent on actual coding than on infrastructure? Personally I'd do it well before or after, so everybody has enough time to check if the conversion worked properly.
Regards, Eduarc
So this is on me. Basically the issue is that we've got a broken Bazaar branch for the 0.44 release. I've been trying to find ways to work around and still get that data, but I think it is probably past time to give up on it. I doubt that anyone is depending on us releasing further versions of the 0.44 branch.
Let's lay down a timeline at the board meeting this week and move forward with JFDI'ing it.
Ted
On 05/31/2017 07:12 AM, Martin Owens wrote:
Hi Bryce + devs,
I'm a bit worried about the Git migration. I'm a bit impatient ;-) but we haven't heard much from KK about availability and I'm thinking we need to plan a contingency.
Thoughts?
Are we planning to get this done at the hackfest?
Best Regards, Martin Owens
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Ted,
I agree... 0.44 really isn't that important (in fact I doubt any branches other than trunk and 0.92.x will be of practical importance) and if I'm not mistaken we could always import additional branches in future (if really required).
Two things that probably are relevant though:
* You mentioned you were looking into importing commits that happened before bzr revision 1. Did you succeed with that? It's probably not that important either, but *if* we want to do it, we obviously have to do it now. * Do you somehow migrate the Bazaar-specific commit metadata? We definitely should make the information on which bugs a commit fixed available and bzr revisions might be handy, too (otherwise the information in a lot of commit messages and bug reports will become useless without constantly falling back to a bzr repository).
As I mentioned before I did some digging on the second bullet point. I'm afraid there is no perfect way to do that (git notes would be a nice possibility in theory but they're not fetched by default and are supported by neither GitHub nor GitLab, so the information would be invisible in most cases and therefore useless). However it should be relatively easy to patch Bazaars fast-export module to include this data in the commit messages. I'd be happy to help out with that if required, so let me know what you think!
Best Regards, Eduard
Am 31.05.2017 um 15:50 schrieb Ted Gould:
So this is on me. Basically the issue is that we've got a broken Bazaar branch for the 0.44 release. I've been trying to find ways to work around and still get that data, but I think it is probably past time to give up on it. I doubt that anyone is depending on us releasing further versions of the 0.44 branch.
Let's lay down a timeline at the board meeting this week and move forward with JFDI'ing it.
Ted
On 05/31/2017 07:12 AM, Martin Owens wrote:
Hi Bryce + devs,
I'm a bit worried about the Git migration. I'm a bit impatient ;-) but we haven't heard much from KK about availability and I'm thinking we need to plan a contingency.
Thoughts?
Are we planning to get this done at the hackfest?
Best Regards, Martin Owens
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Eduard and Ted,
If I remember the process correctly, each of the branches isn't a case of a fresh import since each git fast-import creates new hashes, and idealy you'd watch the hashes of commits to mesh.
Instead what you do is create a fast-export from bzr of our trunk, and then fast-import it into git, taking care to then rewind it to the branch point in the git history and then fast-forward over a cropped version of a fast-export from the branch, thus adding any of the extra commits 'on the end' of that branch.
If there's any issues with the fast-import or export, I've bashed the code a bit, so do let us know and we might be able to help.
Best Regards, Martin Owens
On Wed, 2017-05-31 at 17:02 +0200, Eduard Braun wrote:
Hi Ted, I agree... 0.44 really isn't that important (in fact I doubt any branches other than trunk and 0.92.x will be of practical importance) and if I'm not mistaken we could always import additional branches in future (if really required). Two things that probably are relevant though: You mentioned you were looking into importing commits that happened before bzr revision 1. Did you succeed with that? It's probably not that important either, but *if* we want to do it, we obviously have to do it now. Do you somehow migrate the Bazaar-specific commit metadata? We definitely should make the information on which bugs a commit fixed available and bzr revisions might be handy, too (otherwise the information in a lot of commit messages and bug reports will become useless without constantly falling back to a bzr repository). As I mentioned before I did some digging on the second bullet point. I'm afraid there is no perfect way to do that (git notes would be a nice possibility in theory but they're not fetched by default and are supported by neither GitHub nor GitLab, so the information would be invisible in most cases and therefore useless). However it should be relatively easy to patch Bazaars fast-export module to include this data in the commit messages. I'd be happy to help out with that if required, so let me know what you think! Best Regards, Eduard
Am 31.05.2017 um 15:50 schrieb Ted Gould:
So this is on me. Basically the issue is that we've got a broken Bazaar branch for the 0.44 release. I've been trying to find ways to work around and still get that data, but I think it is probably past time to give up on it. I doubt that anyone is depending on us releasing further versions of the 0.44 branch.
Let's lay down a timeline at the board meeting this week and move forward with JFDI'ing it.
Ted
On 05/31/2017 07:12 AM, Martin Owens wrote:
Hi Bryce + devs,
I'm a bit worried about the Git migration. I'm a bit impatient ;- ) but we haven't heard much from KK about availability and I'm thinking we need to plan a contingency.
Thoughts?
Are we planning to get this done at the hackfest?
Best Regards, Martin Owens
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Has anyone already had a look on how this will work with the ppas?
(I think they're currently pulling their code from the bzr branches directly, and might need to be pointed to a new source, if that's how it works... or a mirror on lp needs to be established, maybe? Or maybe, this isn't an issue at all?)
Regards, Maren
Am 31.05.2017 um 17:16 schrieb Martin Owens:
Hi Eduard and Ted,
If I remember the process correctly, each of the branches isn't a case of a fresh import since each git fast-import creates new hashes, and idealy you'd watch the hashes of commits to mesh.
Instead what you do is create a fast-export from bzr of our trunk, and then fast-import it into git, taking care to then rewind it to the branch point in the git history and then fast-forward over a cropped version of a fast-export from the branch, thus adding any of the extra commits 'on the end' of that branch.
If there's any issues with the fast-import or export, I've bashed the code a bit, so do let us know and we might be able to help.
Best Regards, Martin Owens
On Wed, 2017-05-31 at 17:02 +0200, Eduard Braun wrote:
Hi Ted, I agree... 0.44 really isn't that important (in fact I doubt any branches other than trunk and 0.92.x will be of practical importance) and if I'm not mistaken we could always import additional branches in future (if really required). Two things that probably are relevant though: You mentioned you were looking into importing commits that happened before bzr revision 1. Did you succeed with that? It's probably not that important either, but *if* we want to do it, we obviously have to do it now. Do you somehow migrate the Bazaar-specific commit metadata? We definitely should make the information on which bugs a commit fixed available and bzr revisions might be handy, too (otherwise the information in a lot of commit messages and bug reports will become useless without constantly falling back to a bzr repository). As I mentioned before I did some digging on the second bullet point. I'm afraid there is no perfect way to do that (git notes would be a nice possibility in theory but they're not fetched by default and are supported by neither GitHub nor GitLab, so the information would be invisible in most cases and therefore useless). However it should be relatively easy to patch Bazaars fast-export module to include this data in the commit messages. I'd be happy to help out with that if required, so let me know what you think! Best Regards, Eduard
Am 31.05.2017 um 15:50 schrieb Ted Gould:
So this is on me. Basically the issue is that we've got a broken Bazaar branch for the 0.44 release. I've been trying to find ways to work around and still get that data, but I think it is probably past time to give up on it. I doubt that anyone is depending on us releasing further versions of the 0.44 branch.
Let's lay down a timeline at the board meeting this week and move forward with JFDI'ing it.
Ted
On 05/31/2017 07:12 AM, Martin Owens wrote:
Hi Bryce + devs,
I'm a bit worried about the Git migration. I'm a bit impatient ;- ) but we haven't heard much from KK about availability and I'm thinking we need to plan a contingency.
Thoughts?
Are we planning to get this done at the hackfest?
Best Regards, Martin Owens
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, 2017-05-31 at 17:37 +0200, Maren Hachmann wrote:
Has anyone already had a look on how this will work with the ppas?
(I think they're currently pulling their code from the bzr branches directly, and might need to be pointed to a new source, if that's how it works... or a mirror on lp needs to be established, maybe? Or maybe, this isn't an issue at all?)
This part is actually easier than it seems. You point the launchpad project at the git repository for import into bzr, and then you set the bzr branch to build as usual.
Martin,
Am 31.05.2017 um 18:23 schrieb Martin Owens:
On Wed, 2017-05-31 at 17:37 +0200, Maren Hachmann wrote:
Has anyone already had a look on how this will work with the ppas?
(I think they're currently pulling their code from the bzr branches directly, and might need to be pointed to a new source, if that's how it works... or a mirror on lp needs to be established, maybe? Or maybe, this isn't an issue at all?)
This part is actually easier than it seems. You point the launchpad project at the git repository for import into bzr, and then you set the bzr branch to build as usual.
Martin,
Good to know there's a solution, and someone knows how to set it up :D
Maren
On 05/31/2017 10:02 AM, Eduard Braun wrote:
As I mentioned before I did some digging on the second bullet point. I'm afraid there is no perfect way to do that (git notes would be a nice possibility in theory but they're not fetched by default and are supported by neither GitHub nor GitLab, so the information would be invisible in most cases and therefore useless). However it should be relatively easy to patch Bazaars fast-export module to include this data in the commit messages.
Sure, I think that'd be helpful. Do you have a patch set somewhere I could try out? I think that if we just put the "LP: #123" in the commit message that'd help a lot.
Ted
On 05/31/2017 10:16 AM, Martin Owens wrote:
If there's any issues with the fast-import or export, I've bashed the code a bit, so do let us know and we might be able to help.
I started down that route, unfortunately it is way before that in the repository itself. There seems to be a missing link inside the Bazaar repo. I finally ended up with this being the minimum needed to recreate:
$ bzr branch lp:~inkscape.dev/inkscape/RELEASE_0_44_BRANCH bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit ('spellipse.cpp-20091128124040-aej0x7yhxng1m6ly-3465',) corrupt: line 'njh@...3538... line-delta 12021 197 1 ': Parent index refers to a revision which does not exist yet. 1 > 1
Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 930, in exception_to_return_code return the_callable(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 1121, in run_bzr ret = run(*run_argv) File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 673, in run_argv_aliases return self.run(**all_cmd_args) File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 697, in run return self._operation.run_simple(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 136, in run_simple self.cleanups, self.func, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups result = func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/bzrlib/builtins.py", line 1507, in run source_branch=br_from) File "/usr/lib/python2.7/dist-packages/bzrlib/bzrdir.py", line 367, in sprout create_tree_if_local=create_tree_if_local) File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 132, in run self.cleanups, self.func, self, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups result = func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/bzrlib/bzrdir.py", line 417, in _sprout result_repo.fetch(source_repository, fetch_spec=fetch_spec) File "/usr/lib/python2.7/dist-packages/bzrlib/vf_repository.py", line 1268, in fetch find_ghosts=find_ghosts, fetch_spec=fetch_spec) File "/usr/lib/python2.7/dist-packages/bzrlib/decorators.py", line 218, in write_locked result = unbound(self, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/bzrlib/vf_repository.py", line 2585, in fetch find_ghosts=find_ghosts) File "/usr/lib/python2.7/dist-packages/bzrlib/fetch.py", line 77, in __init__ self.__fetch() File "/usr/lib/python2.7/dist-packages/bzrlib/fetch.py", line 104, in __fetch self._fetch_everything_for_search(search_result) File "/usr/lib/python2.7/dist-packages/bzrlib/fetch.py", line 132, in _fetch_everything_for_search stream, from_format, []) File "/usr/lib/python2.7/dist-packages/bzrlib/vf_repository.py", line 2043, in insert_stream src_format, is_resume) File "/usr/lib/python2.7/dist-packages/bzrlib/vf_repository.py", line 2107, in insert_stream_without_locking self.target_repo.texts.insert_record_stream(substream) File "/usr/lib/python2.7/dist-packages/bzrlib/knit.py", line 1591, in insert_record_stream for record in stream: File "/usr/lib/python2.7/dist-packages/bzrlib/knit.py", line 1398, in get_record_stream ordering, include_delta_closure): File "/usr/lib/python2.7/dist-packages/bzrlib/knit.py", line 1411, in _get_remaining_record_stream build_details = self._index.get_build_details(keys) File "/usr/lib/python2.7/dist-packages/bzrlib/knit.py", line 2540, in get_build_details parent_map = self.get_parent_map(keys) File "/usr/lib/python2.7/dist-packages/bzrlib/knit.py", line 2617, in get_parent_map self._load_prefixes(prefixes) File "/usr/lib/python2.7/dist-packages/bzrlib/knit.py", line 2692, in _load_prefixes _load_data(self, fp) File "bzrlib/_knit_load_data_pyx.pyx", line 304, in bzrlib._knit_load_data_pyx._load_data_c (bzrlib/_knit_load_data_pyx.c:3006) File "bzrlib/_knit_load_data_pyx.pyx", line 298, in bzrlib._knit_load_data_pyx.KnitIndexReader.read (bzrlib/_knit_load_data_pyx.c:2860) File "bzrlib/_knit_load_data_pyx.pyx", line 274, in bzrlib._knit_load_data_pyx.KnitIndexReader.process_next_record (bzrlib/_knit_load_data_pyx.c:2667) File "bzrlib/_knit_load_data_pyx.pyx", line 229, in bzrlib._knit_load_data_pyx.KnitIndexReader.process_one_record (bzrlib/_knit_load_data_pyx.c:2312) KnitCorrupt: Knit ('spellipse.cpp-20091128124040-aej0x7yhxng1m6ly-3465',) corrupt: line 'njh@...3538... line-delta 12021 197 1 ': Parent index refers to a revision which does not exist yet. 1 > 1
bzr 2.8.0dev1 on python 2.7.13 (Linux-4.11.0-3-generic-x86_64-with- Ubuntu-17.04-zesty) arguments: ['/usr/bin/bzr', 'branch', 'lp:~inkscape.dev/inkscape/RELEASE_0_44_BRANCH'] plugins: bash_completion[2.8.0dev1], changelog_merge[2.8.0dev1], grep[2.8.0dev1], launchpad[2.8.0dev1], netrc_credential_store[2.8.0dev1], news_merge[2.8.0dev1], po_merge[2.8.0dev1], weave_fmt[2.8.0dev1] encoding: 'utf-8', fsenc: 'UTF-8', lang: 'en_US.UTF-8'
*** Bazaar has encountered an internal error. This probably indicates a bug in Bazaar. You can help us fix it by filing a bug report at https://bugs.launchpad.net/bzr/+filebug including this traceback and a description of the problem.
Ted
On 05/31/2017 11:23 AM, Martin Owens wrote:
On Wed, 2017-05-31 at 17:37 +0200, Maren Hachmann wrote:
Has anyone already had a look on how this will work with the ppas?
(I think they're currently pulling their code from the bzr branches directly, and might need to be pointed to a new source, if that's how it works... or a mirror on lp needs to be established, maybe? Or maybe, this isn't an issue at all?)
This part is actually easier than it seems. You point the launchpad project at the git repository for import into bzr, and then you set the bzr branch to build as usual.
And Launchpad has git repo mirroring now. So we probably don't even need to convert to Bazaar.
Ted
Am 01.06.2017 um 06:51 schrieb Ted Gould:
Sure, I think that'd be helpful. Do you have a patch set somewhere I could try out? I think that if we just put the "LP: #123" in the commit message that'd help a lot.
I'll check it out (probably this evening) and let you know as soon as I have something to test. I just wanted to know if my input was needed/wanted before putting more work in it.
Anything on the other bullet point (bzr revision < 1)? I guess it would be enough to convert revisions < 1 and current trunk to git seperately and then stitch them together as explained at https://stackoverflow.com/questions/1220557/how-do-i-prepend-history-to-a-gi... (probably the grafts + git filter-branch variant as we are still free to "rewrite history").
Regards, Eduard
Thanks Eduard,
I need you to reply to all of Tad's messages ;-) because his emails are being black holed somewhere :-/ by gmail and I don't get anything.
Ted: I'm not sure how the commit from 2009 is killing a branch who's last commit was in 2006, but I tested locally and got the same error. We could try the 'Upgrade this branch' link on launchpad, that oculd pull the branch into a newer format for us to work with.
Martin,
On Thu, 2017-06-01 at 10:18 +0200, Eduard Braun wrote:
Am 01.06.2017 um 06:51 schrieb Ted Gould:
Sure, I think that'd be helpful. Do you have a patch set somewhere I could try out? I think that if we just put the "LP: #123" in the commit message that'd help a lot.
I'll check it out (probably this evening) and let you know as soon as I have something to test. I just wanted to know if my input was needed/wanted before putting more work in it.
Anything on the other bullet point (bzr revision < 1)? I guess it would be enough to convert revisions < 1 and current trunk to git seperately and then stitch them together as explained at https://stackoverflow.com/questions/1220557/how-do-i-prepend-history- to-a-git-repo/1547490#1547490 (probably the grafts + git filter-branch variant as we are still free to "rewrite history").
Regards, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, May 31, 2017 at 06:36:10PM +0200, Maren Hachmann wrote:
Am 31.05.2017 um 18:23 schrieb Martin Owens:
On Wed, 2017-05-31 at 17:37 +0200, Maren Hachmann wrote:
Has anyone already had a look on how this will work with the ppas?
(I think they're currently pulling their code from the bzr branches directly, and might need to be pointed to a new source, if that's how it works... or a mirror on lp needs to be established, maybe? Or maybe, this isn't an issue at all?)
This part is actually easier than it seems. You point the launchpad project at the git repository for import into bzr, and then you set the bzr branch to build as usual.
Martin,
Good to know there's a solution, and someone knows how to set it up :D
Yeah this isn't something to worry about, I've also set them up.
However, if our longer term objective involves migrating entirely off launchpad we'll want to keep an eye out for potential services to replace the PPAs (or roll our own build system I suppose.) Would be nice to have something able to build all our platforms not just linux...
Bryce
Am 01.06.2017 um 10:18 schrieb Eduard Braun:
Am 01.06.2017 um 06:51 schrieb Ted Gould:
Sure, I think that'd be helpful. Do you have a patch set somewhere I could try out? I think that if we just put the "LP: #123" in the commit message that'd help a lot.
I'll check it out (probably this evening) and let you know as soon as I have something to test. I just wanted to know if my input was needed/wanted before putting more work in it.
Anything on the other bullet point (bzr revision < 1)? I guess it would be enough to convert revisions < 1 and current trunk to git seperately and then stitch them together as explained at https://stackoverflow.com/questions/1220557/how-do-i-prepend-history-to-a-gi... (probably the grafts + git filter-branch variant as we are still free to "rewrite history").
All right, I just created a fast-export patch, see https://bugs.launchpad.net/inkscape/+bug/1695103
It will create commit messages like
$ git log 48125f06a4fa059ff678284fc104a0b861343acc commit 48125f06a4fa059ff678284fc104a0b861343acc Author: marenhachmann <> Date: Fri May 13 22:04:14 2016 +0200
[Bug #1579939] Ramdom color extension improvements (and new unit test file).
Fixed bugs: - https://launchpad.net/bugs/1579939
Original authors: - marenhachmann - jazzynico <nicoduf@...48...>
(bzr r14884)
(fixed bugs, any additional authors (jazzynico in this example) and the bzr revision would otherwise be lost in the conversion process)
Fields can obviously be adjusted freely...
Regards, Eduard
On Fri, 2017-06-02 at 01:22 +0200, Eduard Braun wrote:
Am 01.06.2017 um 10:18 schrieb Eduard Braun:
Am 01.06.2017 um 06:51 schrieb Ted Gould:
Sure, I think that'd be helpful. Do you have a patch set somewhere I could try out? I think that if we just put the "LP: #123" in the commit message that'd help a lot.
I'll check it out (probably this evening) and let you know as soon as I have something to test. I just wanted to know if my input was needed/wanted before putting more work in it.
Anything on the other bullet point (bzr revision < 1)? I guess it would be enough to convert revisions < 1 and current trunk to git seperately and then stitch them together as explained at https://stackoverflow.com/questions/1220557/how-do-i-prepend-histor y-to-a-git-repo/1547490#1547490 (probably the grafts + git filter-branch variant as we are still free to "rewrite history").
All right, I just created a fast-export patch, see https://bugs.launchpad.net/inkscape/+bug/1695103
It will create commit messages like
$ git log 48125f06a4fa059ff678284fc104a0b861343acc commit 48125f06a4fa059ff678284fc104a0b861343acc Author: marenhachmann <> Date: Fri May 13 22:04:14 2016 +0200
[Bug #1579939] Ramdom color extension improvements (and new unit test file).
Fixed bugs: - https://launchpad.net/bugs/1579939
Original authors: - marenhachmann - jazzynico <nicoduf@...48...>
(bzr r14884)
(fixed bugs, any additional authors (jazzynico in this example) and the bzr revision would otherwise be lost in the conversion process)
Fields can obviously be adjusted freely...
This is really cool. Thanks Eduard!
I wonder, is there a way to modify the export to export branches as git branches? It's probably a bit extra crazy, but it'd be so nice to have a one shot 'export' that gives you coherent branches instead of separate repositories.
I'm going to think about it, maybe there's a way to automate. Although maybe Ted's managed to sort everything out manually.
Best Regards, Martin Owens
Am 02.06.2017 um 05:02 schrieb Martin Owens:
I wonder, is there a way to modify the export to export branches as git branches? It's probably a bit extra crazy, but it'd be so nice to have a one shot 'export' that gives you coherent branches instead of separate repositories.
I'm going to think about it, maybe there's a way to automate. Although maybe Ted's managed to sort everything out manually.
That's already happening. Using bzr fast-export / git fast-import with marks (see for example [1]) let's you import as many bzr branches as you want into a single git repo. The marks take care that commits are not imported multiple times but properly linked in history instead.
Ted experimented with the lp2gh Python script which does exactly the same internally but in an automated way.
Regards, Eduard
[1] http://blog.timmattison.com/archives/2011/06/13/how-to-convert-from-bzr-to-g...
On 06/01/2017 06:22 PM, Eduard Braun wrote:
All right, I just created a fast-export patch, see https://bugs.launchpad.net/inkscape/+bug/1695103
Very cool. I'm not too worried about the CPU performance, the whole import and copy I think is network bound (at least at my house) so I don't think there'll be any practical slow down by the revision lookup.
Thanks! Ted
On 06/02/2017 03:04 AM, Eduard Braun wrote:
Ted experimented with the lp2gh Python script which does exactly the same internally but in an automated way.
Yeah, still using that. It seems to be setting up all the branches correctly. I think the only argument might be that it copies too many branches. But I figure we can move them all, and then delete if they become a problem. Easier to destroy than create :-)
Ted
On 06/01/2017 11:32 AM, Martin Owens wrote:
Ted: I'm not sure how the commit from 2009 is killing a branch who's last commit was in 2006, but I tested locally and got the same error. We could try the 'Upgrade this branch' link on launchpad, that oculd pull the branch into a newer format for us to work with.
Tried that, crashed on LP :-)
Ted
participants (5)
-
Bryce Harrington -
Eduard Braun -
Maren Hachmann -
Martin Owens -
Ted Gould