0

We are migrating SVN to Git. On a project.

Everything is well but I have a problem with preserving the permissions (file mode) of some untracked (ignored) dirs and files. We the following process:

  • CleanUp the SVM repo (tidy up, clean uncommited stuff and so forth)
  • svn2git on local environment (migrating from networked SVN - so latest rev, no further commits, this does include a proper authors.txt mapping and proper tracking of branches, tags, etc.)
  • Create ignored files & dirs li (.gitignore)st - partially automated from svn propget, manual finish (row by row)

  • Add the remote and push to it (We're using github but it should hardly matter)

    At this stage the remote is ready, all the history is converted. Now comes the hard part I want to hot-migrate the server deployments without changing the dirs, moving files or creating symlinks. Let's say there are two mirrored environments are on two different servers - one for beta and one for prod. Let us say the dir is /var/www/depl/ for example/. The thing is that as every Web project, there are dirs and files that we don't need to track. I will be writing my steps wit the commands since I think it could also be a nice guide for others. So the strategy for on the servers is:

  • Go there cd /var/www/depl/

  • BackUp to another dir via rsync and preserve the permissions as they are!!
  • Delete all .svn directories recursively find -type d -name .svn -exec rm -rf {} \;
  • Init an empty git repo git init (notice we're not using a 'bare' repo)
  • Add the GitHub remote and call it "origin", also download all branches git remote add -f https://github.com/ORG/REPO
  • Check status (the local copy should be clean)
  • Pull (so fetch + merge but it is actually only a merge) git pull origin master

This last step is what breaks my permissions. Remember those files that I don't want/need to track? It now seems that those have their permissions modified. They are all properly ignored but when I apply the pull/merge it breaks. OK, for sure the issue is coming from the remote repository and via the merge. And it is not an issue, but rather how the files were commited (with what file modes).

The question is: At the last step, when pulling the updates in, can I instruct git to preserve the current file permissions for all files? As in the current dir and recursively down? So: do not change any local permissions?

Yes, maybe I will have a diff and stuff to commit afterwards, but that is not such a big issue as are the broken permissions.

So? Is there a way? The servers are running Linux of course.

Thanks in advance.

Cheers!

Borislav Sabev
  • 4,776
  • 1
  • 24
  • 30

1 Answers1

0

Well, I managed to find a way. The 'secret', as I thought, was in using rsync. I actually solved my issue, while I was writing the question. :)

Anyway, after some research it turns out that rsync --archive will update the target's permissions provided that the timestamps didn't change. The SAMBA mailing list helped a lot! A prerequisite is that you ensure that NOTHING WILL CHANGE in those dirs - so put the website in maintenance mode, stop all crons. Make it inaccessible so you don't have headaches later.

The migration (after you have migrated all you history into git) steps are as follows:

  • Take your production env to the SVN stage that you desire - update, checkout etc. Make sure that this is the same as the incommig git copy and/or keep your changes in patches.
  • BackUp the deployment directory with rsync rsync -av --progress /var/www/depl/ /var/www/deplBackUp1/ - notice that this includes the .svn dirs
  • Delete the .svn dirs: cd /var/www/delp/ find -type d -name .svn -exec rm -rf {} \;
  • Now backUp again in a different location rsync -av --progress /var/www/depl/ /var/www/deplBackUp2/ - the goal is to have two copies
  • Init the new git repo git init
  • Add a remote git remote add -f REMOTE_NAME https://github.com/ORG/REPO
  • Pull everything in from the branch you desire git pull origin master
  • Now rsync back from your (no-.svn dir backUp) rsync -av --progress /var/www/deplBackUp2/ /var/www/depl

You may also want to look into using bare git repositories for your server deployments.

This last step will fix any file mode issues you may have created with your new VCS. If you ever need to do this and run into trouble, tag me in a comment - I will try to help. Cheers!

Borislav Sabev
  • 4,776
  • 1
  • 24
  • 30