Merge lp:~zyga/tarmac/git-support into lp:tarmac
| Status: | Needs review |
|---|---|
| Proposed branch: | lp:~zyga/tarmac/git-support |
| Merge into: | lp:tarmac |
| Diff against target: |
235 lines (+31/-30) 6 files modified
.bzrignore (+1/-0) tarmac/bin/commands.py (+5/-5) tarmac/branch.py (+2/-2) tarmac/tests/__init__.py (+3/-3) tarmac/tests/test_branch.py (+11/-11) tarmac/tests/test_commands.py (+9/-9) |
| To merge this branch: | bzr merge lp:~zyga/tarmac/git-support |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| dobey | 2015-06-09 | Needs Information on 2015-07-07 | |
|
Review via email:
|
|||
Description of the Change
aa97679 Rename Branch to BzrBranch
fb93a53 Ignore .pyc files
This branch is meant to get started with adding git support to tarmac. I'd like to see how conductive upstream is with this move and start making the necessary changes.
| Zygmunt Krynicki (zyga) wrote : | # |
Thanks for the feedback!
I'll continue working on this and I'll be pushing more branches as I
make progress. I'll focus on separating the bzr bits so that git can
co-exist. As for testing, do you intend to have a single set of tests
that work for git and bzr together?
Thanks
ZK
On Tue, Jul 7, 2015 at 7:14 PM, Rodney Dawes <email address hidden> wrote:
> Review: Needs Information
>
> This specific change looks OK to me, but it implies there is an idea about how to get to the end goal. I'd like to know what the ideas of how to get to the end goal of this are, before landing this change, though.
>
> There's a lot of ugliness in the current tests that I think could/should be cleaned up first, for example. Abstracting the bzr integration away and switching to use mocking in the tests, instead of creating actual branches and performing actions in them, will make things more reliable, and easy to repeat across VCS implementations.
> --
> https:/
> You are the owner of lp:~zyga/tarmac/git-support.
| dobey (dobey) wrote : | # |
I think for the tests, each layer will need to be tested separately. The
abstraction would have tests, the underlying bzrlib back-end with its
own tests, and the git back-end with its tests.
On Tue, 2015-07-07 at 17:27 +0000, Zygmunt Krynicki wrote:
> Thanks for the feedback!
>
> I'll continue working on this and I'll be pushing more branches as I
> make progress. I'll focus on separating the bzr bits so that git can
> co-exist. As for testing, do you intend to have a single set of tests
> that work for git and bzr together?
>
> Thanks
> ZK
>
> On Tue, Jul 7, 2015 at 7:14 PM, Rodney Dawes <email address hidden> wrote:
> > Review: Needs Information
> >
> > This specific change looks OK to me, but it implies there is an idea about how to get to the end goal. I'd like to know what the ideas of how to get to the end goal of this are, before landing this change, though.
> >
> > There's a lot of ugliness in the current tests that I think could/should be cleaned up first, for example. Abstracting the bzr integration away and switching to use mocking in the tests, instead of creating actual branches and performing actions in them, will make things more reliable, and easy to repeat across VCS implementations.
> > --
> > https:/
> > You are the owner of lp:~zyga/tarmac/git-support.
>
Unmerged revisions
- 434. By Zygmunt Krynicki on 2015-06-09
-
Ignore .pyc files
Signed-off-by: Zygmunt Krynicki <email address hidden>
- 433. By Zygmunt Krynicki on 2015-06-09
-
Rename Branch to BzrBranch
This patch is meant to test the waters. My goal is to add git support to
tarmac. This change is a harmless change of tarmac.branch. Branch to
tarmac.branch. BzrBranch, this is in anticipation of subsequent add to
GitBranch and subsequent changes as they show up.Signed-off-by: Zygmunt Krynicki <email address hidden>

This specific change looks OK to me, but it implies there is an idea about how to get to the end goal. I'd like to know what the ideas of how to get to the end goal of this are, before landing this change, though.
There's a lot of ugliness in the current tests that I think could/should be cleaned up first, for example. Abstracting the bzr integration away and switching to use mocking in the tests, instead of creating actual branches and performing actions in them, will make things more reliable, and easy to repeat across VCS implementations.