-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 ?

Thai Tran
  • 103
  • 4
  • 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 06 '18 at 08: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 06 '18 at 09: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 06 '18 at 10:55
  • Using branches for making customized versions of the same product was never a good idea. There have been several similar questions asked about this topic in the past, and the top answers all say "don't use branches for this". Sidenote: my downvote is for not informing yourself about the branching capabilities of SVN first. – Doc Brown Feb 06 '18 at 11:52
  • 3
    Possible duplicate of [How can customer specific implementation be handled?](https://softwareengineering.stackexchange.com/questions/343603/how-can-customer-specific-implementation-be-handled) – Doc Brown Feb 06 '18 at 11:52
  • See also: https://softwareengineering.stackexchange.com/q/302147/9113 – Doc Brown Feb 06 '18 at 11:56
  • @DocBrown i don't know why you assume that I don't know about branching in SVN, while I already mentioned that we used SVN for a while and also mentioned the branching concept with Git (so yes, the similar knowledge should be applied to SVN). Therefore, i will update my question a bit. I am having this new position with this team and now on the way to reorganise our code base so it does not become a mess later – Thai Tran Feb 06 '18 at 16:02
  • @DocBrown Searching these kinds of question is difficult cos it is too verbose, compared to "how to move files in Scala", thus this question came up here. Thank you for your supportive links, but if you read this whole thread again, you will see that lot of people do not know what to do with this situation (assuming branching is good, which is against with your 2nd link above). So i think my question is not bad, because it helps the community grows and let people know what they don't know. Maybe a comment with a link and without judgement should be fine next time ? ;) – Thai Tran Feb 06 '18 at 16:11
  • 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 06 '18 at 17:33
  • @ThaiTran: You wrote *"If using Git, we can create branches for the base code"* - this gives me a very clear impression you believe if you *not* move to Git, you will not be able to create branches or merge automatically. And your edit now makes the question look strange to me - if you know SVN branches, why don't you use them instead of doing the merges manually? – Doc Brown Feb 06 '18 at 18:38
  • ... however, a "vote for close as a duplicate" is actually no indication that your question is bad. It is just a form of linking two very similar questions together here on this site. – Doc Brown Feb 06 '18 at 18:41
  • If you really think you need to do this with branches, [you might find this SO post](https://stackoverflow.com/questions/471618/subversion-merging-changes-from-a-different-repository) helpful, it is about how to merge changes from one repo into another. – Doc Brown Feb 07 '18 at 06:42

2 Answers2

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"

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
mediterranean
  • 41
  • 3
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)

CharonX
  • 1,633
  • 1
  • 11
  • 23
  • Your answer pretends SVN cannot be used for similar branching as well, and honestly, that is wrong. – Doc Brown Feb 06 '18 at 11:46
  • @Doc Brown I make no single statement about the capabilities of SVN in my answer. – CharonX Feb 06 '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 06 '18 at 12:58
  • I assumed there are reasons why OP does not use e.g. cherry-picking on SVN. Personally I found cherry picking on SVN a bit "klunky", so we did not use it, though that might have been our tool's fault (compared to cherry picking in Git which feels rather easy). – CharonX Feb 06 '18 at 13:21
  • 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 06 '18 at 13:22
  • All of my critics above was about the meaning of your answer, not you in person. Sorry if that sounded "rough" to you, that was not my intention. But to my understanding, your answer is not really accurate. I thought my first comment was clear about this, but your reaction showed you needed further explanation about what how your answer reads to me. I was actually trying to stick to the facts, but again, take my apologies if my comment gave you a different impression. – Doc Brown Feb 06 '18 at 14:09
  • @CharonX :) have a nice day mate – Thai Tran Feb 06 '18 at 16:12
  • @Doc Brown It is alright. And I must apologize for being a bit thin-skinned, it has been a stressful day and - as I said - I have had negative experiences here before. It is just... "Your answer pretends SVN cannot be used... " sounds rather in-your-face-ish to me; kinda as if the answer not only SHOULD know better, but actually DOES know better and purposefully misleads (or something like that). Should I have written "cherry-picking fixes takes less effort"? – CharonX Feb 06 '18 at 16:29
  • 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 06 '18 at 18:50