2

I'm using subgit for two-way sync of an SVN and a Gitlab repo, through intermediate repository (like explained in official docs for connecting to Github. That's a part of a very slow transition process from current SVN to Git.

I don't know if my issue is related to this specific case, but I noticed that SubGit is also synchronizing the properties set on the root folder - those properties being some lock timestamps set up by Subgit itself (like subgit:lock 2018-02-12T17:00:24.067). Those properties are completely irrelevant and not needed as far as SVN side developers are concerned.

The properties are only moved from Git side to SVN. When coming from SVN, there's nothing extraordinary coming in.

Is there a way of preventing SubGit from doing that? I do already use the sync-filtering in the config file, but only for some specific files. How would I do the same for the properties?

Note: For those interested, my scenario was a bit specific: SVN repo is behind VPN, while Gitlab is on a live server, which doesn't have the access to that VPN.

The sync was done through local machine (which had the VPN access) as a proxy.
And it all needed to keep accepting the commits from both SVN and Git(lab) side.

Community
  • 1
  • 1
userfuser
  • 1,350
  • 1
  • 18
  • 32

1 Answers1

2

This subgit:lock (and similar to it) is used to handle the case when 2 users commit to SVN and Git at the same time. In earlier versions SubGit just sent a command that would remove this property (even if it is not set) and that "hack" solved the situation.

Since Subversion 1.9 this stopped working and Subversion started to ignore removal of non-existing properties. So SubGit started to set subgit:lock to an unique string every time. Unfortunately this resulted into merge conflicts (SGT-1215) and at the moment of writing these lines it sets a property with an unique name but with subgit:lock prefix every time.

As it's difficult to distinguish between 1.8 and 1.9 Subverion server versions, SubGit has this behaviour for SVN 1.8+ verisons but for versions up to 1.7 it still has its old behaviour: removing a non-existing property. Also it has its old behaviour for file:/// protocol access as it doesn't depend on Subversion software version.

At the moment there's no option to turn this new behaviour off, but if this really hurts you, I think we could implement such an option, create an issue in SubGit issue tracker then.

Without subgit:lock property nothing would change significantly if you push 1 commit at a time. But if you push, say, commit A and B at the same time and at the same moment someone commits revision C to SVN, there will be higher probability of ending with C,A,B or A,C,B revisions in the SVN repository as result. So, nothing really serious.

I'm one of SubGit developers.

Dmitry Pavlenko
  • 8,530
  • 3
  • 30
  • 38
  • Thanks 10x for such a detailed explanation. I'm marking this as an answer since it seems the best one I will get. Why was this an issue - I'm not sure if it really caused problems that I had, but I had some very strange behavior with .ignore files, while syncing, often causing issues on SVN side, and moving too much files to it - even when not changed. Pretty much, I was never sure how many files will be moved to SVN as "new" ones, although they were old, but the parent folder changed. I can say that it was happening in combo with changed .ignore file, but don't know more than that. – userfuser Feb 13 '18 at 15:01
  • This `.gitignore` problem you describe is absolutely another problem and has nothing to do with `subgit:lock`. I don't want to hijack this topic, so I'll just note: "to avoid problems, make sure all your .gitignore lines start with slash(/)". `.gitignore` patterns not containing slashes are recursive, but `svn:ignore` property is not recursive, so SubGit applies it recursively to SVN if there's no slash. If you need more information, contact support@subgit.com. – Dmitry Pavlenko Feb 13 '18 at 16:16
  • Thanks for the additional input, it may very easily be what you mention. I did see that part in the docs. Though, there was some stranger behavior with .gitignore (multiple, intertwined histories of the .gitignore, that never existed in original SVN), so eventually I wasn't ever sure what's going to happen next, at least in svn-subgit-git-phpstorm combo. But, as mentioned, let's not expand here. – userfuser Feb 13 '18 at 20:50
  • BTW, I may have left a wrong impression here, but subgit is a very useful piece of software and the docs are actually also decent. I did have some hellish weeks until it all worked as I wanted, but - a man needs his challenges. :) Of course, when you know exactly what you do and have the time to do it, then it gets much easier. – userfuser Feb 13 '18 at 20:51