Git-svn support gone in latest arc? Plans for a grand return?

I’ve been working on upgrading our ancient Arc install to the latest version (yay lockdown projects - the stacked land support would be a great addition for our git-svn users, which I’m trying to encourage) and porting over aik099’s various SVN improvement patches to it. (I’d love to try and bring some of these upstream if you’re open to it, particularly the ones that fix support for newer SVN client versions - I know there’s been some alignment issues in the past though.)

It looks like all the git-svn logic has been lost in arc land, and it doesn’t seem to be doing the right thing automatically any more (following the reproduction steps from T13293 as I can never remember how to setup git-svn :slight_smile:). Reading through the release notes I can’t see any mention of support being dropped (only HgSubversion in T13547) - so is it just temporarily lost and on the near-term plans for support? lost but not currently planned? or removed and forgotten for the release notes?

arc2 below is 2565cc7 2020 Week 27 + patches), arc is 4d22e0f 2019 Week 10 + patches. The set of patches in each case are slightly different, but none of them touch the land workflow or any of the git repository API pieces.

I’m very happy to give this a shot at bringing into the new workflow if you’re a) happy to have it, b) consider the previous implementation roughly reasonable, and c) don’t think you’ll be getting to it for a while. It’d probably be in the order of months though, as I’m currently trying to move countries in the middle of all this!

[root@TPS-POR-ASHER1 git-svn-test]# arc2 --config 'repository.callsign=SVNTEST' land
 STRATEGY  Merging with "squash" strategy, the default strategy.
 SOURCE  Landing the current branch, "arcpatch-D6580".
 ONTO REMOTE  Landing onto remote "origin", the default remote under Git.
 USAGE EXCEPTION  No pushable remote "origin" exists. Use the "--onto-remote" flag to choose a valid, pushable remote to land changes onto.
[root@TPS-POR-ASHER1 git-svn-test]# arc --config 'repository.callsign=SVNTEST' land
Landing current branch 'arcpatch-D6580'.
Switched to branch master. Updating branch...
The following commit(s) will be landed:

f5d1f10 Update the README regarding Lemons

Switched to branch arcpatch-D6580. Identifying and merging...
Landing revision 'D6580: Update the README regarding Lemons'...
 BUILDS  Checking build status...
 BUILDS PASSED  Harbormaster builds for the active diff completed successfully.
Pushing change...

Committing to svn+ssh:// ...
Committed r9
r9 = 1a9ca8f48cb77cb8fb4a9abdbefa9d8a01a49adb (refs/remotes/git-svn)
No changes between 92957b9c05feebe5f43519f7371bd22eb0105b64 and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn

Cleaning up feature branch...
(Use `git checkout -b 'arcpatch-D6580' 'f5d1f10f85c19e035aa99ab0480476859a032f2b'` if you want it back.)

Mercurial/SVN and Git/SVN support are currently at risk because I’m not aware of any customers using either VCS system. If at least two customers for each system don’t crawl out of the woodwork soon (in most cases, I won’t build or maintain systems used by only one customer nowadays), I don’t expect to restore support for either one.

I’ll update the notes to explicitly mention Git/SVN – I’d initially planned to maintain support since it seems more widely used than Mercurial/SVN, but it didn’t end up making it given the complexity of Git/SVN support, and that change got lost between merging and release notes.

I can never remember how to setup git-svn

Yeah, me neither.

a) happy to have it

I’d like it to be in use by at least two Phacility customers to commit to maintaining it. I’m currently aware of zero customers using it.

b) consider the previous implementation roughly reasonable

I suspect the previous implementation would need to be significantly rewritten to work with newly-introduced arc land concepts and workflows, like MarkerQuery. That said, I haven’t set up Git/SVN in many years – since almost no one uses it – and don’t even really know what the old implementation did.

As a possible path forward, arc land should now generally be modular, so it should be possible to implement Git/SVN support purely as an extension. If you attempt this and run into trouble, I am open to upstream changes to improve modularity.

(For example, there may currently be no way to force Arcanist to build a GitSVNAPI object when the working directory is a valid Git repository and can construct a valid GitAPI object, but this is reasonable to add support for.)

Thanks for the reply - that’s slightly sad news but totally understandable. I’ll take a look at the extension route when things quieten down a bit, thanks!

and don’t even really know what the old implementation did.

Off the top of my head from when I was working on it before, but I think the gist of it is:

  1. Figure out what branch is tracking the SVN trunk (that’s what I fixed previously)
  2. Merge to that branch (like master in normal Git - it is actually master in most setups)
  3. Run git svn dcommit on that branch, rather than git push

I was looking though the new arc land earlier and it looks like all the new flags might actually be a path forward in the interim, but I haven’t really dug into that - but if it is possible to tell arc to only do the “merge” and not push, it might be possible for people to run the dcommit themselves manually at least.