Re: [git-users] Large SVN to GIT migration

[Kevin Norton]

Thanks Mark,

  All advice so far seems to trend towards taking opportunity to clean up 
repository. I'm doing a walk through Clone of latest Dev Branch into GIT. I 
want to see how to manage the Clone and then keep synchronized. And then 
evenutally push or clone into a central repository that Developers would 
connect to.

Kevin

On Thursday, November 3, 2016 at 3:58:12 PM UTC-7, Mark Waite wrote:
>
>
>
> On Thursday, November 3, 2016 at 10:31:08 AM UTC-6, Kevin Norton wrote:
>>
>> Thanks Magnus,
>>
>> i will explore subgit, but i think i'm leaning towards simplifying my 
>> repo and trimming un-needed branches and history.
>>
>
> When we did a major transition from a previous source control system to 
> git, it was easiest and simplest to take a snapshot of the tip of the 
> relevant branches from the source repository, then place them into the new 
> git repository.  Developers who want to see the history before the 
> transition referred to the earlier repository.  Developers who want the 
> history after the transition referred to the git repository.
>
> I think that had several benefits:
>
>1. Don't mislead developers to think that the history in git is 
>authoritative for those commits before git was used.  The authoritative 
>history is in the original repository
>2. Don't clutter the new repository with history that precedes the 
>transition to git
>3. Don't spend time trying to create and revise a translation system 
>when the translated result will not be authoritative
>
> I'm sure there are business conditions where that is not acceptable 
> (transition from a licensed, proprietary source control system which will 
> be unavailable after the transition), but it worked well for us, and it 
> wasn't too long before searches in the old repository dropped to almost 
> zero.
>
>
> Mark Waite
>  
>
>> Kevin
>>
>> On Thursday, November 3, 2016 at 1:18:53 AM UTC-7, Magnus Therning wrote:
>>>
>>>
>>> Kevin Norton  writes: 
>>>
>>> > i'm in the process of coming up with a strategy to convert a very 
>>> large 
>>> > project from SVN to GIT. 
>>> > 
>>> > i'm experimented with git svn clone but have some questions. 
>>> > 
>>> > how large is to large. 
>>> > 
>>> > current SVN repo 
>>> > 80K+ revisions. 
>>> > suffers from poor SCM practices 
>>> > current structure in SVN is using cascading hierarchy. Essentially 
>>> each 
>>> > release branch becomes the trunk (not officially named as trunk) and 
>>> then 
>>> > next release branches to start next development release branch and so 
>>> on, 
>>> > Think of a stairway. 
>>> > Essentially current code sitting in Trunk is extremely old, relevant 
>>> code 
>>> > is at the end of the branching staircase. 
>>> > 
>>> > My first issue i'm trying to sort out. 
>>> > Should i migrate the entire SVN repo into a staging GIT repo and then 
>>> clean 
>>> > up the GIT repo before pushing to eventual network repo for all 
>>> developers. 
>>> > Will it even clone at this size? 
>>> > Or i could clone only the latest release branch and start this as my 
>>> Master 
>>> > in GIT. 
>>> > Questions with this approach are how do i keep it from walking the 
>>> branches 
>>> > back through entire SVN repo? 
>>> > Only way I've seen so far is to specify SVN revision. Is there another 
>>> > approach i'm overlooking. 
>>> > Advantage here is smaller conversion but i'm loosing history or have 
>>> to 
>>> > maintain a legacy SVN repo for historical. (maybe its not important?) 
>>> > 
>>> > any experience or suggestions with the above are appreciated. 
>>>
>>> Just bumped into this too 
>>> https://github.com/svn-all-fast-export/svn2git. In particular this 
>>> passage sounds like it could be interesting: 
>>>
>>>   The svn2git repository gets you an application that will do the actual 
>>>   conversion. The conversion exists of looping over each and every 
>>>   commit in the subversion repository and matching the changes to a 
>>>   ruleset after which the changes are applied to a certain path in a git 
>>>   repo. 
>>>
>>> I don't know, but maybe you can come up with rules that'll convert your 
>>> "staircase development" in SVN to a more common "single branch 
>>> development with release branches"? 
>>>
>>> /M 
>>>
>>> -- 
>>> Magnus Therning  OpenPGP: 0x927912051716CE39 
>>> email: mag...@therning.org   jabber: mag...@therning.org 
>>> twitter: magthe   http://therning.org/magnus 
>>>
>>> We act as though comfort and luxury were the chief requirements of 
>>> life, when all that we need to make us happy is something to be 
>>> enthusiastic about. 
>>>  — Albert Einstein 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Large SVN to GIT migration

[Mark Waite]

On Thursday, November 3, 2016 at 10:31:08 AM UTC-6, Kevin Norton wrote:
>
> Thanks Magnus,
>
> i will explore subgit, but i think i'm leaning towards simplifying my repo 
> and trimming un-needed branches and history.
>

When we did a major transition from a previous source control system to 
git, it was easiest and simplest to take a snapshot of the tip of the 
relevant branches from the source repository, then place them into the new 
git repository.  Developers who want to see the history before the 
transition referred to the earlier repository.  Developers who want the 
history after the transition referred to the git repository.

I think that had several benefits:

   1. Don't mislead developers to think that the history in git is 
   authoritative for those commits before git was used.  The authoritative 
   history is in the original repository
   2. Don't clutter the new repository with history that precedes the 
   transition to git
   3. Don't spend time trying to create and revise a translation system 
   when the translated result will not be authoritative

I'm sure there are business conditions where that is not acceptable 
(transition from a licensed, proprietary source control system which will 
be unavailable after the transition), but it worked well for us, and it 
wasn't too long before searches in the old repository dropped to almost 
zero.


Mark Waite
 

> Kevin
>
> On Thursday, November 3, 2016 at 1:18:53 AM UTC-7, Magnus Therning wrote:
>>
>>
>> Kevin Norton  writes: 
>>
>> > i'm in the process of coming up with a strategy to convert a very large 
>> > project from SVN to GIT. 
>> > 
>> > i'm experimented with git svn clone but have some questions. 
>> > 
>> > how large is to large. 
>> > 
>> > current SVN repo 
>> > 80K+ revisions. 
>> > suffers from poor SCM practices 
>> > current structure in SVN is using cascading hierarchy. Essentially each 
>> > release branch becomes the trunk (not officially named as trunk) and 
>> then 
>> > next release branches to start next development release branch and so 
>> on, 
>> > Think of a stairway. 
>> > Essentially current code sitting in Trunk is extremely old, relevant 
>> code 
>> > is at the end of the branching staircase. 
>> > 
>> > My first issue i'm trying to sort out. 
>> > Should i migrate the entire SVN repo into a staging GIT repo and then 
>> clean 
>> > up the GIT repo before pushing to eventual network repo for all 
>> developers. 
>> > Will it even clone at this size? 
>> > Or i could clone only the latest release branch and start this as my 
>> Master 
>> > in GIT. 
>> > Questions with this approach are how do i keep it from walking the 
>> branches 
>> > back through entire SVN repo? 
>> > Only way I've seen so far is to specify SVN revision. Is there another 
>> > approach i'm overlooking. 
>> > Advantage here is smaller conversion but i'm loosing history or have to 
>> > maintain a legacy SVN repo for historical. (maybe its not important?) 
>> > 
>> > any experience or suggestions with the above are appreciated. 
>>
>> Just bumped into this too 
>> https://github.com/svn-all-fast-export/svn2git. In particular this 
>> passage sounds like it could be interesting: 
>>
>>   The svn2git repository gets you an application that will do the actual 
>>   conversion. The conversion exists of looping over each and every 
>>   commit in the subversion repository and matching the changes to a 
>>   ruleset after which the changes are applied to a certain path in a git 
>>   repo. 
>>
>> I don't know, but maybe you can come up with rules that'll convert your 
>> "staircase development" in SVN to a more common "single branch 
>> development with release branches"? 
>>
>> /M 
>>
>> -- 
>> Magnus Therning  OpenPGP: 0x927912051716CE39 
>> email: mag...@therning.org   jabber: mag...@therning.org 
>> twitter: magthe   http://therning.org/magnus 
>>
>> We act as though comfort and luxury were the chief requirements of 
>> life, when all that we need to make us happy is something to be 
>> enthusiastic about. 
>>  — Albert Einstein 
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Large SVN to GIT migration

[Kevin Norton]

Thanks Magnus,

i will explore subgit, but i think i'm leaning towards simplifying my repo 
and trimming un-needed branches and history.

Kevin

On Thursday, November 3, 2016 at 1:18:53 AM UTC-7, Magnus Therning wrote:
>
>
> Kevin Norton  writes: 
>
> > i'm in the process of coming up with a strategy to convert a very large 
> > project from SVN to GIT. 
> > 
> > i'm experimented with git svn clone but have some questions. 
> > 
> > how large is to large. 
> > 
> > current SVN repo 
> > 80K+ revisions. 
> > suffers from poor SCM practices 
> > current structure in SVN is using cascading hierarchy. Essentially each 
> > release branch becomes the trunk (not officially named as trunk) and 
> then 
> > next release branches to start next development release branch and so 
> on, 
> > Think of a stairway. 
> > Essentially current code sitting in Trunk is extremely old, relevant 
> code 
> > is at the end of the branching staircase. 
> > 
> > My first issue i'm trying to sort out. 
> > Should i migrate the entire SVN repo into a staging GIT repo and then 
> clean 
> > up the GIT repo before pushing to eventual network repo for all 
> developers. 
> > Will it even clone at this size? 
> > Or i could clone only the latest release branch and start this as my 
> Master 
> > in GIT. 
> > Questions with this approach are how do i keep it from walking the 
> branches 
> > back through entire SVN repo? 
> > Only way I've seen so far is to specify SVN revision. Is there another 
> > approach i'm overlooking. 
> > Advantage here is smaller conversion but i'm loosing history or have to 
> > maintain a legacy SVN repo for historical. (maybe its not important?) 
> > 
> > any experience or suggestions with the above are appreciated. 
>
> Just bumped into this too 
> https://github.com/svn-all-fast-export/svn2git. In particular this 
> passage sounds like it could be interesting: 
>
>   The svn2git repository gets you an application that will do the actual 
>   conversion. The conversion exists of looping over each and every 
>   commit in the subversion repository and matching the changes to a 
>   ruleset after which the changes are applied to a certain path in a git 
>   repo. 
>
> I don't know, but maybe you can come up with rules that'll convert your 
> "staircase development" in SVN to a more common "single branch 
> development with release branches"? 
>
> /M 
>
> -- 
> Magnus Therning  OpenPGP: 0x927912051716CE39 
> email: mag...@therning.orgjabber: mag...@therning.org 
>  
> twitter: magthe   http://therning.org/magnus 
>
> We act as though comfort and luxury were the chief requirements of 
> life, when all that we need to make us happy is something to be 
> enthusiastic about. 
>  — Albert Einstein 
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Large SVN to GIT migration

[Magnus Therning]

Kevin Norton  writes:

> i'm in the process of coming up with a strategy to convert a very large
> project from SVN to GIT.
>
> i'm experimented with git svn clone but have some questions.
>
> how large is to large.
>
> current SVN repo
> 80K+ revisions.
> suffers from poor SCM practices
> current structure in SVN is using cascading hierarchy. Essentially each
> release branch becomes the trunk (not officially named as trunk) and then
> next release branches to start next development release branch and so on,
> Think of a stairway.
> Essentially current code sitting in Trunk is extremely old, relevant code
> is at the end of the branching staircase.
>
> My first issue i'm trying to sort out.
> Should i migrate the entire SVN repo into a staging GIT repo and then clean
> up the GIT repo before pushing to eventual network repo for all developers.
> Will it even clone at this size?
> Or i could clone only the latest release branch and start this as my Master
> in GIT.
> Questions with this approach are how do i keep it from walking the branches
> back through entire SVN repo?
> Only way I've seen so far is to specify SVN revision. Is there another
> approach i'm overlooking.
> Advantage here is smaller conversion but i'm loosing history or have to
> maintain a legacy SVN repo for historical. (maybe its not important?)
>
> any experience or suggestions with the above are appreciated.

Just bumped into this too
https://github.com/svn-all-fast-export/svn2git. In particular this
passage sounds like it could be interesting:

  The svn2git repository gets you an application that will do the actual
  conversion. The conversion exists of looping over each and every
  commit in the subversion repository and matching the changes to a
  ruleset after which the changes are applied to a certain path in a git
  repo.

I don't know, but maybe you can come up with rules that'll convert your
"staircase development" in SVN to a more common "single branch
development with release branches"?

/M

--
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
enthusiastic about.
 — Albert Einstein

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [git-users] Large SVN to GIT migration

[Magnus Therning]

Kevin Norton  writes:

> i'm in the process of coming up with a strategy to convert a very large
> project from SVN to GIT.
>
> i'm experimented with git svn clone but have some questions.
>
> how large is to large.
>
> current SVN repo
> 80K+ revisions.
> suffers from poor SCM practices
> current structure in SVN is using cascading hierarchy. Essentially each
> release branch becomes the trunk (not officially named as trunk) and then
> next release branches to start next development release branch and so on,
> Think of a stairway.
> Essentially current code sitting in Trunk is extremely old, relevant code
> is at the end of the branching staircase.
>
> My first issue i'm trying to sort out.
> Should i migrate the entire SVN repo into a staging GIT repo and then clean
> up the GIT repo before pushing to eventual network repo for all developers.
> Will it even clone at this size?
> Or i could clone only the latest release branch and start this as my Master
> in GIT.
> Questions with this approach are how do i keep it from walking the branches
> back through entire SVN repo?
> Only way I've seen so far is to specify SVN revision. Is there another
> approach i'm overlooking.
> Advantage here is smaller conversion but i'm loosing history or have to
> maintain a legacy SVN repo for historical. (maybe its not important?)
>
> any experience or suggestions with the above are appreciated.

It's worth taking a look at https://subgit.com/ to see if that tool can
simplify the conversion. It's proprietary, but the licensing is
reasonable (https://subgit.com/pricing.html).

/M

--
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

Never be afraid to try something new. Remember, amateurs built the
ark; professionals built the Titanic.
 — Anonymous

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[git-users] Large SVN to GIT migration

[Kevin Norton]

i'm in the process of coming up with a strategy to convert a very large 
project from SVN to GIT.

i'm experimented with git svn clone but have some questions.

how large is to large.

current SVN repo 
80K+ revisions.
suffers from poor SCM practices
current structure in SVN is using cascading hierarchy. Essentially each 
release branch becomes the trunk (not officially named as trunk) and then 
next release branches to start next development release branch and so on, 
Think of a stairway.
Essentially current code sitting in Trunk is extremely old, relevant code 
is at the end of the branching staircase.

My first issue i'm trying to sort out. 
Should i migrate the entire SVN repo into a staging GIT repo and then clean 
up the GIT repo before pushing to eventual network repo for all developers. 
Will it even clone at this size?
Or i could clone only the latest release branch and start this as my Master 
in GIT. 
Questions with this approach are how do i keep it from walking the branches 
back through entire SVN repo? 
Only way I've seen so far is to specify SVN revision. Is there another 
approach i'm overlooking.
Advantage here is smaller conversion but i'm loosing history or have to 
maintain a legacy SVN repo for historical. (maybe its not important?)

any experience or suggestions with the above are appreciated.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.