Hi,
we’re evaluating SubGit for two-way synchronization based on https://subgit.com/documentation/github.html, and are very happy with the initial results.
Before moving forward towards production usage with more users (~100) and a license purchase, we have some concerns regarding synchronization conflicts and monitoring, that we’d like to discuss with you - the experts.
Would it be possible to discuss these details with you?
Cheers,
Felix Nieuwenhuizen
Hi Felix,
glad to hear you got good results with SubGit!
Sure, we would be glad to help you with anything you need. Could you please share your concerns and how do you want to discuss them.
Hi Ildar,
Thanks for the quick response!
Some background info to our current setup, so you have an idea what we’re working with and we don’t have to spend time discussing this online.
We’re looking for migration paths from SVN to Git.
A “big bang” migration would be difficult due to the number of users and build processes involved, so we’re looking for solutions for a transition
period where SVN and Git are kept in sync.
We have servers hosting our existing SVN repos (VisualSVN), and servers hosting our Git repos (BitBucket).
They a different servers, and unfortunately, it’s not feasible we’ll be able to install anything on these servers (large company and separation of
concerns…).
Also, using your “SVN Mirror for Bitbucket Server” does not seem to be an option.
IT seemed open to installing the plugin, but the licensing makes it impossible – the Bitbucket instance has 20000+ (registered) users, but we’d only
need the plugin for maybe 100-200 users.
According to IT, project specific plugins or licensing to a subset of users is not possible at the moment.
So it seems we have use a setup with three separate machines: one hosting SVN, one hosting Git, and one running SubGit.
This is our setup:
We followed these instructions to set it up:
https://subgit.com/documentation/github.html
#1 & #2 are the standard SubGit actions (Git to SVN with post-receive hook and SVN to Git with SVN poll).
#3 is a user-post-receive hook with “git push”, as described in your documentation (section 1.4).
#5 is a script to “git fetch” and “git push”, as described in your documentation (section 1.5). It is currently executed on a timer, but we might move
to triggering this with Bitbucket hooks.
Now, this is working very well in a proof-of-concept setup, synchronizing two-way.
I’ve attached the config file for one of our repos.
We’d like to move to a field test with more users, but have a few concerns.
The documentation says “We recommend to disable write access to GitHub repository and submit any Git changes through SubGit mirror only.”
I’m assuming this is because there is no way to prevent conflicts between the two Git repos with quasi-simultaneos commits – correct?
From your experience, is this more a hypothetical concern, or will this cause lots of headaches in a productive use with users from both sides?
If we go forward with this setup, are there mechanisms in place for monitoring, detecting conflicts and resolving conflicts?
Could we discuss this (and maybe other questions) with you in an online meeting?
Would next Monday (March 8) work for you, 13:00 – 14:00 (German time)?
If that’s an inconvenient time in your timezone, please let me know.
config (20.6 KB)
Hi Felix,
thank you for detailed explanation!
Actually, you are right, conflict is the main reason for that recommendation, not the “quasi-simultaneos commits” (if I got correctly what you meant), but conflicts between content of the SubGit repository and Bitbucket repository, I would say. For example, consider a situation when a new branch is created in SVN: SubGit will recognize it and translate if to Git and it will be then pushed to the Bitbucket repository. But after that the script #5 would fetch it and may try to push it back to SubGit which is not desirable at least (may cause problems as well). So to use the Bitbucket repository as the main repository for developers the script #5 must be smart enough to at least recognize commits that came from SVN in the first place. If the changes are being pushed to SubGit repository, then it handles all of that, but when Bitbucket is the main repository, then all those tasks fall to the script, it should be able to handle all the conflicts. I wouldn’t say that is only a hypothetical concern, it may bring a lot of headaches.
As for the online meeting – sure, we could discuss that. It may happen that I won’t be available on Monday, but my colleagues will be glad to help. The time frame seems to be ok, but we’ll discuss it further tomorrow and let you know. Do you have any preferences for the meeting software?