1

I have trouble with my development flow..

I have two machines, F and O, both are offline and isolated. F is the main development machine and is connected to and SVN repo. O is also a development machine but without any form of version control. Code developed in F is tested in F then copied in O, tested again and modified, then again copied in F and committed to SVN.

This is done every week. It's tedious, prone to errors, and I lose every edit done on O.

My idea is perform git-svn on F, git clone that repo in a bare repo on usb, and use this bare repo to track changes on O, then pull from this updated bare on F and dcommit con the SVN.

I know it's not good but I have no better idea... Any suggestions?

yeppe
  • 679
  • 1
  • 11
  • 43
Delcaran
  • 19
  • 1
  • 3
  • Why do you think it's not good? Not bad, IMHO. Should work. The only minor issues you might get is handling file permissions properly and the usb stick going dead. Latter should not be an issue as you still have repo clones on both F and O. – Mykola Gurov Sep 21 '16 at 14:29
  • "For the sake of simplicity and interoperating with Subversion, it is recommended that all git svn users clone, fetch and dcommit directly from the SVN server, and avoid all git clone/pull/merge/push operations between Git repositories and branches. The recommended method of exchanging code between Git branches and users is git format-patch and git am, or just 'dcommit’ing to the SVN repository.". This is written in the git-svn page of the docs and it makes me think my idea is not good enough... – Delcaran Sep 21 '16 at 16:42
  • Well, that's true to an extent, especially when you start to get high volume of concurrent changes. The most important is to avoid "merges" and use rebases instead, which can make concurrent development more challenging. In the case you have more sequential and coordinated changes, your idea should work. – Mykola Gurov Sep 22 '16 at 10:25

1 Answers1

0

The full list of recommendations is available here, which does illustrate that working on a cloned Git repository is possible

In your case, it is simpler since you will not svn dcommit from the cloned Git repo in O.
You can import your Git history back to the Git bare repo in F, and dcommit from there, as long as (as commented):

  • there is no Git merge, and
  • the history remains linear (new commits added to what was previously git svn fetch).
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250