Small fixes and improvements to docs

[michaliskambi]

This contains four (actually separate) small fixes/improvements:

• The fix to main sync2git script to work with default GIT repository layout created by recent git-svn, see explanation in commit log 1002f55 . Note that I did not test whether this is backward-compatible with existing repositories created by old git-svn (and synchronized with old sync2git versions). Possibly this should be implemented better:) Anyway, at least this makes sync2git work with what git-svn creates by defaut,.
• The fix to svn-authors-extract: the "grep" trick requires the SVN output language to be English.
• Small improvements/clarifications to the README.txt file.
• And a small addition: a trivial script sync2git-logger, useful to redirect sync2git to log file. I found it useful for me, but feel free to reject this change of course:)

Finally - many thanks for creating this script:) I use it to synchronize from SVN various repositiories of my "Castle Game Engine", https://github.com/castle-engine :)

[ntwb]

@dpocock Any chance you'd be able to look at merging this?

[michaliskambi]

Note that my fork received some additional commits in the meantime. Feel free to apply them too, or reject them:) The original fixes should of course still work Ok, the additional work (described below) is only activated by special definitions in the repository config file (/etc/sync2git/projects/xxx/config).

The history behind these changes is that as I was playing more and more with GIT and GitHub, I wanted to be able to commit to Git too, especially to merge pull requests people send through Github. So the initial sync2git functionality (synchronize SVN->GIT) was not enough for me. This resulted in 2 new features:

1. A hacky way to make a 2-way synchronization, so you can commit to any repository (SVN or GIT) and it gets synchronized to the other one. Implemented by this commit: ab3a96c . You need to define COMMIT_GIT_TO_SVN=true in the repository config file.

   See also Feature request: two-way integration, to be able to apply changes to GIT back to SVN #8 .

   Disadvantages: This synchronization sometimes needs to "forcefully push" to GIT, which overrides GIT commit hashes and authors. Explanation: If you commit something directly to the Git repository (by normal pushing, or by merging someone's pull request), then run the synchronization, the commits will be applied back to SVN, and then they will be applied back to GIT --- but with a different hash than original (and a different author, the one derived from SVN committer, and a little different log, with "git-svn" comment added). That's how git-svn works by default.

   That's either a big or a small problem, depending on how extensively you use the GIT repository. The GIT authors are overridden, which isn't nice to your GIT contributors that submit pull requests. More importantly, they need to carefully do "git pull --rebase", since the GIT commit hashes just totally changed. If they were in the middle of some new contributions, based on their previous contributions, and you just applied their previous contributions --- they will need to reapply their new work on top of new hashes.

2. To overcome the above disadvantage, later I added a 1-way synchronization GIT->SVN, that does not override GIT commit hashes. The GIT repository is only read in this case (you can even enable GitHub "protected branches" feature). This is used if you define ONLY_COMMIT_GIT_TO_SVN=true in the config file.

   Of course it assumes you will not commit anything to SVN anymore. Only the sync2git will commit to SVN, everyone else should only push to GIT.

   It works a little differently than other options, using "git svn commit-diff" under the hood. Multiple GIT commits may be glued into a single SVN commit (that's how "git svn commit-diff" works by default, some work would be required to overcome this). An example how this works is in https://sourceforge.net/p/castle-engine/code/15282/ , this SVN commit came from 4 GIT commits: castle-engine/castle-game@0b760fb , castle-engine/castle-game@0b3a0c5 , castle-engine/castle-game@ba7b4b6 , castle-engine/castle-game@15b618e .

   It uses /var/lib/sync2git/xxx/last-committed-revision-to-svn.txt to record last synchronized GIT commit hash. In each run, it adds newly found GIT commits as a single SVN commit, constructing nice log for it.

   It also works to synchronize GIT "master" to SVN "trunk", and doesn't deal with tags or branches at all. It really just works totally differently than original approach, much simpler but only 1-way GIT->SVN.

   This is implemented by cf6f507 and 234402f .

[dpocock]

@michaliskambi thanks for your work on commit back to SVN.

Personally, if I want to make commits, I am usually not sending them back to SVN. If I have control over the SVN repository, I shut it down and make Git the official repository. Otherwise, I do the following:

• I create two repositories in Github, e.g. foo-mirror and foo
• I use sync2git to replicate SVN into foo-mirror. I do not make any commits in foo-mirror myself
• I clone from foo-mirror, create a branch and make all my own commits on that branch
• then I push from that clone to foo
• whenever something changes in the master branch in foo-mirror, I pull that into my clone, merge it into my branch and then push that to foo

I haven't had time to review the pull request so far, I am travelling at the moment

[dpocock]

@michaliskambi thanks for this, I'm also curious about the impact of using origin with existing repositories.

I'm only mirroring seven projects right now so it may not be a lot of trouble to test this change. What testing would you suggest is necessary before this is merged?

[michaliskambi]

I'm only mirroring seven projects right now so it may not be a lot of trouble to test this change. What testing would you suggest is necessary before this is merged?

If you start with a new repository, and try to synchronize it, things should work fine with my fork:)

If you have created the (git-svn) repository using the current (your) version of sync2git, and with an earlier Git (before 2.0), so that your remotes are not inside origin/ , then you may need to upgrade it.

This could be detected by doing

/var/lib/sync2git/<your-project>/svn-clone/
git show-ref

If you see there refs/remotes/origin/trunk, then you're all set. If not, you probably should move the "refs" under the prefix origin/ . I have not investigated how to do so...

Edit: Aside from the upgrade path (what happens if you try my fork on current repos), for testing, one should check how my fork works with new repos of course:) All 3 synchronization options

• 1 way SVN->GIT,
• 2 way SVN->GIT, GIT->SVN,
• 1 way GIT->SVN.

Yesterday I updated the README in my fork to somewhat document the additional options. Personally, I'm only using the 3rd option now (GIT->SVN) to keep my old SVN repositories in sync, so I admit I have not tested the other options since some time:)