4

I'm a software developer recently in charge of entire project (project manager). The project I'm working on (with 6 other persons) is a complex Java-based application that's being developed for over 5 years. The entire time we were using SVN, without branching. Now, I would like to switch to Git as I do believe Git will provide superior branching and ease some development.

Anyway, before I do switch, I have to tell you about the current workflow we're having with SVN, I have to hear opinion from people experienced with Git and to tell you what are the things I expect from Git. Please tell me if Git can provide the things I need the way I need them, because if I switch the entire project to Git and then it turns out I have to revert it to SVN (for any reason), I would be dead :) .

The principle we're following with SVN is:

  • Each team member is working on a single feature. When such feature is done, a local copy of dev's code is updated against SVN master and feature is deployed for testing. If testing by clients passed, the person developing the code pushes it to our main (and only) branch with a proper commit message that explains the feature, ticket number and so on.

  • If, during "update before deploying for testing" the team member gets into conflicts, he's cherry-picking conflicting files line by line.

  • When time comes that we deploy new features to production, I load the production code from a particular folder on the disk (like "physical branch"), I sync that code to the current state of the SVN, going class by class, reviewing committed changed and taking the code meant for that particular deploy. Usually, it happens that out of 230 classes we have in the repo (and not in production workspace) bewteen 30 and 50 classes are with conflicts because of the features we don't need on production yet. Sometimes, clients ask for the latest features before wanting some older features. If both feature they want and features they don't affect the same file, I have to manually skip some particular file from commit version number 3 to commit version number 6 without taking any changes from commits 4 or 5. Now, if another file is also affected, it happens that another file from version, say, 35, I have to update to version 40 without taking any changes done between 35 and 40. With SVN, it's easy, I sync a particular file and pick only the lines of codes ignoring all others. It takes time but I am in a position to tell clients "we'll postpone this for X days".

Also, if two developers are working on different features that largely affect the same subsystem or big number of the same files, in order to avoid nasty conflicts and collisions I usually tell clients "we can't develop both things in the same time, we'll postpone feature B till feature A is done and tested" and one of the devs get to work on something else.

Now, from Git the only thing I basically need is:

  • Nice Windows GUI (for SVN we're using "Subclipse" plugin for Eclipse). I'm really not into investing a lot of time just learning or remembering how to push a branch or view the history or do something similar if it can be done with the click of a button. For me, the version control system should be just a tool - not something my devs should spend more than a day learning how to use because of CLI and advanced things we'll never use or require. With SVN we use only 4 commands: commit, update, synchronize (to see the differences) and "history". Ok, sometimes we do use "compare with version X from repo" but not so often.
  • The ability to achieve nice code storage by using only a few basic commands (button clicks to be precise :D ): push / pull, fetch / commit, branch / merge, view history. Nothing fancy or advanced which would take a lot of time to learn or understand.
  • The ability to partially take commits. For example: commit consists of 10 files. I take all changes from 8 files, but for two files I do cherry-pick in a manner that from current production version 5 I take two lines of code from file commit version 7 and few lines from file commit version 9 (effectively keeping those two files in "undefined version" so that I can supply my clients with the newest changes without all code changes preceding that newest feature I want). To achieve this point, for me it's not a problem to allocate an entire day digging through history and commits regardless if it's SVN or Git. That's my "preparing deploy" day anyway :)
  • Having numerical commit versions, not HASH-based ones!

Is it possible with Git? I really have limited experience with Git, only on some small projects and I can't afford to move the entire code base from one system to another :( Please give me some advice.

  • 2
  • 9
    So you're dead set on doing lots of menial work to avoid learning how to properly use version control? – CodesInChaos Jun 29 '17 at 15:47
  • 4
    All of the things mentioned under “what I need from Git” (fully featured GUI, only a few simple commands, very advanced cherry-picking, sequential commit IDs) run against the nature of Git. None of these are entirely impossible, but you're setting yourself up for a lot of pain. Given this SVN workflow, you're better of with SVN or another modern VCS. Git is super powerful and can likely make your life easier, but not without changing your workflow (e.g. proper branching instead of cherry-picking). – amon Jun 29 '17 at 16:30
  • 4
    "Not something my devs should spend more than a day learning how to use because of CLI and advanced things we'll never use or require." Lol. But let's spend 100s of man-hours manually picking line-by-line changes, instead. – Alexander Jun 29 '17 at 17:22
  • 3
    @guest86 You expect a tool to meet your complex needs, you can't expect it to be a one click solution. It'll take time investment to learn, and there will growing pains as developers get up to speed on it – Alexander Jun 29 '17 at 17:47
5

IMHO you are approaching this from the wrong side. You probably need first and foremost a better workflow, utilizing branches, and not necessarily another tool. Why not start using feature branches with SVN? If you are going to develop two major features in parallel, just create individual branches for the features and assign them as a temporary "work space" for the part of the team which is going to implement the features.

That is a fairly simple and easy to grasp branching model, SVN supports this well, and as long as the centralized repo model of SVN is not a problem for your team, it might be all you need. You "newbie" developer will still just use "commit, update, synchronize, history" on the branch you assigned to him (and a daily "merge from trunk into my feature branch"), only the person who will integrate the features back into the trunk some day will have to know some more SVN commands. This integration step will become much easier than you current "cherry picking" approach, since you do not have to sort out which code change belongs to a certain feature afterwards in the cumbersome and error-prone manner you described.

When you go this route and reach the point where you and your team want to do more complex branches, and you notice SVN is not be sufficient any more, for example, when you need a tool for doing distributed, local branches, then it is time to switch to Git. But currently, it seems you are not there yet.

  • Thanks for your answer! So far i never considered SVN as a good branching platforms because wherever i checked "SVN branching" i saw ppl with "panic attacks" that it can break the project, it's unsafe, it's bad and so on :\ If SVN support for branching is safe, then i do think that would be a perfect "initial step" for my team. Some members of my team never used anything other than SVN, in fact for some of them this was their first job 5 years ago :) – guest86 Jun 30 '17 at 13:03
  • 1
    @guest86 Contrary to SVN, branching in Git actually works well. Git is designed from the ground up around branching and merging. Overcoming the SVN-induced "Branchphobia" is an important step in becoming accustomed to Git. – Philipp Jun 30 '17 at 13:18
  • 2
    @guest86: instead of listening to some superstitious believe that only DVCS can be used for branching, I would recommend to try out how far the SVN branching capabilities will bring you. I have used them in my team, for feature branches and bugfix branches as well, and they served us well for all the requirements we had so far. But YMMV. – Doc Brown Jun 30 '17 at 13:23
  • 1
    No, no, if we can create, say, 20 feature branches in SVN on the central server, merge them into "testing" then "production" branches without risk of ruining the repo (due to internal SVN problem) then it's fine. We actually don't need "pull requests" and stuff like that (for now) :) – guest86 Jul 1 '17 at 2:27
  • 1
    Ok, i tested branching with SVN and so far it seems as exactly what i need :) So far it works ok even with complex code-base and complex and messy commits, found no issues. :) Thanks Doc Brown :) – guest86 Jul 3 '17 at 10:34
1

It seems to me from your post that you are not making the best use of source control.

Additionally you say you don't have much experience of using git.

I think its fairly well accepted that git has become the dominant source control software. Possibly you could argue that the git flow branching strategy is the most popular and a robust strategy for beginners to adopt.

However, it doesn't seem likely that you will be able to achieve a productivity increase if you try to switch to git without help.

It seems to me that it will be quite an organisational and culture change to switch to a better use of source control and it should only be attempted by an experienced person with a lot of buy in from the other developers

  • Well that's my #1 problem - none of us have a lot of experience with GIT. I wasn't original member of the team but i'd say even SVN was chosen...maybe incidentally and so far wasn't changed exactly because switching to another source control is a serious and responsible job for complex projects. – guest86 Jun 29 '17 at 17:06
  • With GIT, is it even possible partially taking commits (and keeping files in conflict on purpose)? I know it's a bad practice but with clients we're currently having we have to use that "trick" more often than not :\ – guest86 Jun 29 '17 at 17:07
  • 1
    I would hire a consultant to do some training and manage the change. Or just leave it alone – Ewan Jun 29 '17 at 17:07
  • 1
    it is possible, but like you say, bad practice. you'll just get yourself in a mess unless you know what your doing – Ewan Jun 29 '17 at 17:09
  • I was reading about Mercurial till now. For now, seems like a better choice for me taking into consideration project structure, lack of experience of my team and "junior" status of some members. Seems simpler and safer plus (as we're all using Windows) seems like it has better tools for Windows. I'll continue investigating it. – guest86 Jun 29 '17 at 17:38
1

•Nice Windows GUI (for SVN we're using "Subclipse" plugin for Eclipse). •The ability to achieve nice code storage by using only a few basic commands (button clicks to be precise :D ): push / pull, fetch / commit, branch / merge, view history.

There is a Git integration plugin for Eclipse available from the official Eclipse repository which allows all these operations (under "Collaboration" on the "Install new software..." screen). This plugin is already included in many of the official Eclipse packages, so you might already have it.

The official Git for Windows also comes with a stand-alone GUI. It doesn't expose the full feature-set of Git, but allows the most common operations.

•The ability to partially take commits. For example: commit consists of 10 files. I take all changes from 8 files, but for two files I do cherry-pick in a manner that from current production version 5 I take two lines of code from file commit version 7 and few lines from file commit version 9 (effectively keeping those two files in "undefined version" so that I can supply my clients with the newest changes without all code changes preceding that newest feature I want). To achieve this point, for me it's not a problem to allocate an entire day digging through history and commits regardless if it's SVN or Git. That's my "preparing deploy" day anyway :)

In general, Git encourages you to use lots of branches (usually one branch per feature) and commit often on each branch. Commits should never contain two unrelated changes. This should allow you to cherry-pick the features you want by cherry-picking commits. It also allows you to create a release with only the features your customers request by merging the feature-branches which correspond to these features.

So if you have this requirement, you are using Git wrong.

However, if you are ever in the situation where you need to merge only parts of a commit, you should create a new commit on the feature-branch which reverts the changes you don't want and then merge the branch. If you still want to keep working on the features you don't want to merge into mainline, you would create that commit on a new branch which you merge and keep developing on the old branch.

•Having numerical commit versions, not HASH-based ones!

Sorry, but Git doesn't do that. Git encourages decentralized, parallel development on multiple branches with multiple commits per branch, so incrementing commit numbers just don't fit into the Git philosophy. However, you can use tags in Git to manually assign numbers (or other descriptors) to commits. You can do that on your master-branch after merging from the feature-branches.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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