@Rouleau: Thanks for the reply.

Nope. I have two SVN repositories, where:
- the first repository is the repository before the old VCS crashed.
- the second repository contains all the dev code since the crash with
the history starting from the crash day onwards.

I wish to have a single GIT repository containing the merge of the two
SVN repositories, so that the crash incident does not manifest itself
in anyway. In other words, if a file is present in two SVN
repositories, then it has two distinct histories - the one from its
creation until the crash (in the first repo) and the other  - from the
crash until now (in the new repo). I want this file to have a single
history in the GIT, which is from its creation until now.

On Sep 5, 6:31 pm, P Rouleau <proulea...@gmail.com> wrote:
> I'm not an expert, but it looks like you now have two branches in SVN
> and you want to merge them back, but in git instead. And the hardest
> step will be "finding the time to do it"...
> I understand you want to keep the pre-crash history and the post-crash
> one too. I suggest these steps (look at the doc for the options'
> description):
> 1. git svn clone [-s] -A {authors.lst} svn://pre-crash-svn mergeCrash
> 2. git svn clone [-s] -A {authors.lst} svn://post-crash-svn postCrash
> 3. cd mergeCrash
> 4. git remote add postCrash ../postCrash
> 5. git fetch [--tags] postCrash master
> 6. git merge postCrash/master
>     If you did a lot of modifications in the post-crash branch, this
> is where you will regret it. You will probably use --continue alot.
> 7. git add {conflictedFiles}
> 8. git commit -m "Back to one history, at last"
> 9. git remote add origin g...@thegitserver:project.git
> 10. git push [--tags] origin master
> 11. // start working with the new server and shutdown the SVN ones to
> avoid creating a new mess.
> If step 6 is too challenging, you can simply push the preCrash history
> into a preCrash branch on the new server and simply push the postCrash
> history to the master branch and continue to work from there. You will
> have access to the old history, but it will not be very useful. I'm
> not sure, but if you have many branches, you will have to push them
> also.
> PS: I did not try the steps myself. I have only writed the steps I
> would have plan to do. We have switched from SVN to git not long ago
> and it went very well, but we only had to do step 1, 9 and 10.
> On Sep 5, 3:42 am, Mark Kharitonov <mark.kharito...@gmail.com> wrote:
> > Dear ladies and sirs.
> > We use SVN as our VCS, but wish to migrate to git. All is good, but a
> > few months ago our SVN server had a serious RAID problems (so much
> > that it became unusable) plus at the same day no IT person was
> > available to restore the repository from the backups. So, we have
> > setup a temporary SVN server on a certain workstation from the most
> > recent version that we had. The net result is:
> >    1. We have a few months of work on the temporary SVN server (the
> > revisions there start from 1, of course)
> >    2. There is a new VCS server machine with the pre-crash SVN
> > repository restored there, but no one uses it yet, because someone has
> > to merge the temporary repository there somehow and no one has the
> > time.
> >    3. In addition, we want to migrate to git, because SVN is just too
> > much pain to work with - merges are killing us.
> > Can anyone advice on the best process to end up with a git repository,
> > which would contain the old SVN repository merged with the temporary
> > one?
> > BTW, the new VCS server is a linux machine.
> > Thanks a lot in advance.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to