-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Small fixes and improvements to docs #7
base: master
Are you sure you want to change the base?
Conversation
…ted to keep it that way. Adjust sync2git to honor this. See git-svn manual: --prefix=<prefix> This allows one to specify a prefix which is prepended to the names of remotes if trunk/branches/tags are specified. The prefix does not automatically include a trailing slash, so be sure you include one in the argument if that is what you want. If --branches/-b is specified, the prefix must include a trailing slash. Setting a prefix (with a trailing slash) is strongly encouraged in any case, as your SVN-tracking refs will then be located at "refs/remotes/$prefix/", which is compatible with Git’s own remote-tracking ref layout (refs/remotes/$remote/). Setting a prefix is also useful if you wish to track multiple projects that share a common repository. By default, the prefix is set to origin/. Note Before Git v2.0, the default prefix was "" (no prefix). This meant that SVN-tracking refs were put at "refs/remotes/*", which is incompatible with how Git’s own remote-tracking refs are organized. If you still want the old default, you can get it by passing --prefix "" on the command line (--prefix="" may not work if your Perl’s Getopt::Long is < v2.37).
Clone must indicate --prefix value for following logic to work reliably
Fix clone to indicate --prefix
…that keeps GIT hashes intact.
…vars for multiple projects.
@dpocock Any chance you'd be able to look at merging this? |
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:
|
@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 haven't had time to review the pull request so far, I am travelling at the moment |
@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? |
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
If you see there 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
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:) |
If a network issue disrupts a large a initial clone, then only a partial history is checked out. This state can be recoved by running a fetch. There is no harm in attempting this, so do it unconditionally if the clone already exists.
Add a fetch to be robust against network issues
Can be used for example to ignore some paths in a repository.
Add FETCH_ARGS option to config
This contains four (actually separate) small fixes/improvements:
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 :)