Resolving a non-standard repository layout

[Miguel Romero]

Hi,

Due a client specifications, we have a special projects layout.

For example, We have ONE Jira project EADM (key) and in its subversion, we have several submodules (EADM/ADM.CLI-ADF/codigo, EADM/ADM.CLI-ADF/scripts, and EADM/ADM.CLI-ADM-GENERIC/codigo) every one with (trunk, branches, releases, tags, closed-branches).

I am thinking how can we solve the svn-to-git migration. My first idea is create a reposity.git with each submodule of a project jira and not with each project jira, for example, "EADM/ADM.CLI-ADF/codigo" would be a repository.git, "EADM/ADM.CLI-ADF/scripts" would be another respository.git. But, of this way, I will have several repository.git who I will have to associate to one jira project key. Is that possible?

What is your opinion?

Thanks!

https://bisdev.jira.com/svn/EADM/ --> JIRA Project Key (EADM)

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/codigo/

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/codigo/trunk

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/codigo/branches

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/codigo/releases

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/codigo/tags

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/codigo/closed-branches

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/scripts/

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/scripts/trunk

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/scripts/branches

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/scripts/releases

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/scripts/tags

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADF/scripts/closed-branches

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADM-GENERIC/

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADM-GENERIC/codigo/

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADM-GENERIC/codigo/trunk

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADM-GENERIC/codigo/tags

https://bisdev.jira.com/svn/EADM/ADM.CLI-ADM-GENERIC/codigo/branches

[Miguel Romero · Accepted solution]

Atlassian has commented me the next:

Hi Miguel,

I've spoken with my colleague from the Bitbucket team. The best way to go would be to split up the submodules into separate repo's. With the conversion you will have to specify the locations of branches, tags and trunk.
The new Bitbucket -> Jira integration does not work the same as you are used to with the SVN integration. The integration is not based on links between the Jira project and the repo. "All repo's are integrated with all projects"

The integration kicks in whenever a commit is done with a Jira case in the commit message.

I hope this makes it more clear. Please let me know if you have any additional questions.

Cheers,
Bas

Then We are going to divide our subprojects and repositories and trust in Bitbucket "All repo's are integrated with all projects" to integrate with On Demand

What do you think Lucas? Thanks!

[LucasA]

Hi Miguel,

SVN to GIT migration looks for a standard repository structure. I'm afraid that you have to modify your structure to match with the default one: https://confluence.atlassian.com/display/AOD/Importing+Versioned+Data+into+Subversion

If you need help on this matter, please raise a support ticket at https://support.atlassian.com.

Lucas Lima

Atlassian Support

[Miguel Romero]

I have added an answer for support on demand team.

[Miguel Romero]

Atlassian has commented me the next:

Hi Miguel,

I've spoken with my colleague from the Bitbucket team. The best way to go would be to split up the submodules into separate repo's. With the conversion you will have to specify the locations of branches, tags and trunk.
The new Bitbucket -> Jira integration does not work the same as you are used to with the SVN integration. The integration is not based on links between the Jira project and the repo. "All repo's are integrated with all projects"

The integration kicks in whenever a commit is done with a Jira case in the commit message.

I hope this makes it more clear. Please let me know if you have any additional questions.

Cheers,
Bas

Then We are going to divide our subprojects and repositories and trust in Bitbucket "All repo's are integrated with all projects" to integrate with On Demand

What do you think Lucas? Thanks!