-3

We have several ongoing projects and need to figure out the way to manage the repos.

The current situation is Project A is in production, in a SVN Repo A. Project B is in development for another client and is actually project A with some add-in features, in a SVN Repo B. So every time we have a fix on A, we need to wait for a while to let the fix verified. Meanwhile, B continues to be under development, thus after a while, the code base will be a bit different. Then after the fix is verified, I have to manually track down back to the commit in A, copy/paste the code into B (because they are in different repositories). The whole process is wasting my time. And there gonna be more clients coming later, thus I don't want to have the situation that I have to copy/paste the code across multiple projects (repos).

We are discussing if we should move to Git or keep using SVN. If using Git, we can create branches for the base code, and then each client can be matched with one branch, however, the whole branch concept of master/develop/feature-1,2,3/release-v1,2,3... might collapse. I know branch exists in SVN as well

What is the neat way to organise this situation ?

  • 1
    While knowing SVN just briefly I'd say you should not base your decision on the branching model you have in mind when switching from a centralized SCM to a distributed one. You should discuss with you team whether the work flow changes a distributed SCM enables overule the fact that your team currently is quite efficient in using SVN. – Timothy Truckle Feb 6 '18 at 8:51
  • @TimothyTruckle thank you for your comment. We actually open to any options. The reason we are using SVN is more about the cultural reason (repos are passed from other teams), not because of knowledge limitation. If continue to use SVN, I want to know what is the neat way to handle these situations as well – Thai Tran Feb 6 '18 at 9:01
  • 1
    Personally I prefer Git, but Subversion has branches too, so I don't see any reason you couldn't use a similar branching strategy within a single SVN repository. The main thing is getting away from having to copy/paste between two different repos which really should be branches within one repo. Which VCS you choose to use to do that is a separate matter. – Sean Burton Feb 6 '18 at 10:55
  • 3
    Possible duplicate of How can customer specific implementation be handled? – Doc Brown Feb 6 '18 at 11:52
  • 1
    As a suggestion, I would not look to branching to solve a process problem here. What you're needing to look at is less of an issue with branching, and more of an issue of queuing up a merge from one repository or branch to another. I would suggest examining the process of how you merge changes back and forth more closely, like having a merge request or PR open to repo B while the fix is being tested on A, and block it via the original issue for A. That way, once A's fix checks out, your process can continue for B. This is not a problem that version control should be solving, IMO. – damianb Feb 6 '18 at 17:33
4

Being user of both SVN and GIT, I would say that once get accustomed to SVN, it takes some time to get used to with GIT due to the key difference of being centralized/decentralized among them.Once passed that period, the advantage I felt with Git over SVN that:

  1. Versioning and branching takes less efforts.

  2. If you don't have access to your codebase "server" for some time, it is more easy to manage the repository as its on your local machine and you can commit changes whenever you like.

But still I feel more comfortable to use SVN for "centralized" kind of environment where you have to continuously upload changes to the central repository. Also interms of binary files specially with large size, SVN is better choice. At the time of Switching from SVN to GIT for existing projects you also have to think about "files history"

2

Our project moved from SVN to Git about two years ago, and to be honest, I wouldn't want to trade back. There are quite a few nifty migration tools that allow you to import the SVN commit history into Git, so nothing is lost there. The distributed approach of Git worked out rather well for us too - we use Gitlab as the "master repository" from which our CI etc. draws commits from.

One serious advantage I'd see in your case is being able to easily cherry-pick fixes etc. from your "project A" into "project B" by setting up "project B" as a branch of project A. Don't forget you are able to "tag" certain points in your branch as "release v1", "release v1.1", "release v2" etc. making it less necessary to create a new branch for each release (unless you find a bug that needs to be fixed in release "v1.1" - then you can create a branch, fix the bug, release "v1.1b" - and then cherry pick the fix to your master branch too)

  • Your answer pretends SVN cannot be used for similar branching as well, and honestly, that is wrong. – Doc Brown Feb 6 '18 at 11:46
  • @Doc Brown I make no single statement about the capabilities of SVN in my answer. – CharonX Feb 6 '18 at 12:28
  • Your answer is about "advantages" the OP would get from switching to Git to cherry pick fixes, to set up B as a branch of A, and more, as if that would not be possible when staying with SVN. For me, this reads very clearly as a statement about the non-capabilities of SVN. To be fair, the OP already made this wrong assumption in the question. Don't get me wrong, I am not saying the OP should stay with SVN, I am just saying changing the tool is not the solution he is looking for, changing the branching strategy may help, but that has not much to do with the tool. – Doc Brown Feb 6 '18 at 12:58
  • 1
    As a sidenote: this is my second less-than-pleasant interaction here on softwareengineering - is such a "rough" tone the norm here? If so maybe I should stop answering questions here alltogether. – CharonX Feb 6 '18 at 13:22
  • 1
    @CharonX: maybe I should have written "might give the uninformed reader the impression" instead of "pretends" - english is not my first language, you know. But I think a good answer should emphasize on (tool-indepent) branching&merging, maybe with some secondary reasoning why this could work better with Git, if one thinks that is the case. – Doc Brown Feb 6 '18 at 18:50

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.