I have no experience working with a modern decentralized VCS in a multi-programmer setting. I think it would help me a lot if we nailed down some rules on how our high-level branching will work.
This article struck me as very straightforward. His examples are using the command-line version of Git. I haven't tried it, yet, but I think we can apply them direction to GitHub.
Apparently, this article has prompted plugins for git and GitHub called git-flow and GitHub Flow. It's unclear to me from the articles that I've read whether we need quite that much regimentation.
I think that while it's just the two of us, we should be able to do those steps manually. After we're a little more comfortable with the basic tools, we may find that the automation provided will be welcome.
Let me know what you think.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have you considered using SVN? Both SF and AS natively supports SVN. One lees tool to admin and one less problem in the IDE. For a small project such a this, a decentralized repository such as GIT may be overkill.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think we should stick to the-simpler-the-better-until-we-need-something-more-complicated. So I would start by a single trunk, and just tagging in every release, in case we need to fall back after a big problem. If later we feel that we need further branches, such as temporary branches for large developments (in the eventual case that we really made any large one), we can do it later.
Having lots of branches, such as the one in your first link is a must for large projects. For example, my current main-job project has around 100 developers and, right now, 3 different releases maintained at a time (an old version where we are releasing bug-fixing patches; a release candidate to be delivered this month; and the main long-run development), so that kind of complicated branching is absolutely needed (we have no less than 6 active branches right now, and a few more inactive). But for small projects such as this, I think it just causes lots of bureaucracy and failure-points.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe I misunderstood your requests when you asked me to research and set up this open source system. One of the things you asked for was native support from Android Studio. The only cloud system that Android Studio supports natively is GitHub. But, if you're comfortable pushing and pulling from the cloud manually, then any of the popular version control systems will work with SourceForge.
We could drop GitHub entirely, and go straight to SourceForge. After setting up the system and connecting them, I'm a little less enamored with the convenience of GitHub integration in our situation. Going from there to SourceForge adds extra complication that outweighs the convenience in Android Studio. Using the VCS locally and manual pushing to SourceForge feels like it's going to be more straightforward.
As for which VCS to use, here are my thoughts that lead to my recommendation.
I have used SubVersion in the past. I was working by myself, so it was mainly just a way for me to be able to try stuff out without having to do the "copy everything to another directory" form of version control.
Since you have so much experience with svn, I can understand your reluctance to embrace branching. I had looked at branching in svn, but never felt comfortable actually doing that. It sounded like an advanced concept that required enough understanding and experience to plan ahead for it. I had read about some pitfalls if branches overlapped, especially in a distributed project. It just sounded like something to steer clear from.
Then, I read Joel Spolsky's tutorial on Mercurial. He brought up a few very common scenarios, even with just two people, that illustrated where svn falls down and requires manual merging. The distributed version control systems handle those situations in a much cleaner manner.
My understanding is that they actively encourage branching. Mostly because, they're merging repositories, and not just source files. That brings in a lot more information at the time of the merge, which helps make the merges smoother.
So, my vote would be pretty strongly for either Git or Mercurial. One thing I really liked about svn and hg was TortoiseSVN and TortoiseHG, that hooked into Windows Explorer. There is a (I think) fork called TortoiseGit. But, the description made it sound like it wasn't as mature as the others.
As for the branch naming rules. After reading those pages I pointed to, the main thing that I came away with was it greatly aids organization by being diligent about keeping Master always the last release. And, using Develop as a staging area prior to merging into Master for the next release.
Beyond that, I get the feeling that, with just the two of us, the rest of our branching can be a lot more relaxed, and just for our own personal organization. Even if we pick up a third programmer, chances are, we don't need to define anything any more rigid.
But, if we do find ourselves wishing we understood another guy's branches better, we can go back to those pages and incorporate some of those rules.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please, do not consider this messages as command, but as advice based on my experience with both large and small projects, both corporate and open-source projects. Your experience may be as good as mine and your wish to work gives you the right to have the final decision.
I have used SVN in a lot of projects (it is the VCS I use at home, because it is simple), but also have used other VCS, so I do not mind using others. My experience is that merging problems usually does not have to do with the VCS tool, but with the evolutions in the code itself, people forgetting to merge when needed and things like that. The tool eases or hardens the task, but is not usually them root of problems.
If you feel that two branches (Master and Dev) are a good idea, it is ok for me. Would you code minor bugfixings directly in Master? Or even bugfixing would be done in Dev?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just take into account that AS does support SVN out of the box
I have just noticed that by default it is configured to use a command-line svn (File -> Settings -> Version Control -> Subversion). Just to test, I have configured it, against my own SVN server, by unclicking "Use command line client".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do think of this as your project. You put in all the effort to get it working in the first place, and I want to respect that. And, you'll likely take back over primary control at some point. So, right now, I think your opinions do carry a bit more weight than mine.
Having said that, I am going to make one more push for git or hg, and then you can decide. If you greatly prefer svn, then I can accept that.
Just to give you a little more background on my experience with version control. I'm old enough that, when I started, cheap networks didn't exist. In the small teams I worked on, two to four programmers, we shared code on floppies. About once a month, someone would lose a day or two worth of work, when they copied the work of a colleague onto their machine.
Since then, I used a program for DOS called T-lib, between me and one other coder. Later, still in small groups up to about five or six, we were using SourceSafe. Systems that locked out your teammates while you were working on a particular file.
I worked briefly on one project that used CVS.
All of my experience with svn and hg has been on my own.
As I mentioned before, while trying to understand branching in svn, what I came away with was, Branching is Hard. aka It's easy to screw up and make a mess.
If you don't mind, I would like to ask your opinion of what Joel Spolsky says about Subversion. his contention that, because frequent check-ins pollute the repository with buggy code, that most Subversion users hold off checking in their code for days or weeks, until it's fully debugged. And, also, his "Subversion Story #1" about how hard it is to create and maintain a clean branch of the current shipping code.
Maybe you can give me some tips on how to avoid those two pitfalls? Or, point me at a page or two that you think do a good job of describing efficient ways of working with svn?
Last edit: Drake Christensen 2015-06-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is that written by Spolsky? Then I am temped to just agree without even reading it! I have learnt so many useful things from Spolsky (I almost every week recommend this or this to someone) that every word from his keyboard is to be carefully read.
I have read it and I almost completely agree with him. My only enhancement would be: even the best tool can be a mesh when used wrongly by a team that does not understand it; in such cases a worse-but-more-usual tool can lead to less problems. Actually, the same applies to design patterns, organizational structures, programming languajes and many other things.
If mercurial integration in SF and AS is simple, we can go for it. In the worst case, if we find later that the branching work takes long, we can change mind. I do not mind changing mind after testing it.
I have never used mercurial, but the branching (and local repository) concepts seem pretty similar to GIT (which I have used). And also, the notion of changeset is very similar to the one in MS Team Foundation Server (which is the one we are using in the large project that I described above).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Git and hg are very, very similar. I've seen discussions of special cases where one is better than the other. But, for everyday use, they're conceptually identical.
Spolsky's company Fog Creek even has a service called Kiln, that provides a repository that both git and hg can talk to. One developer can use git and another hg, both on the same repository.
And, like you, I have enough experience to know that any tool can be misused. That's why I was wanting to nail down some minimal rules on the branching stuff. I think if we stick to a couple of simple rules to guide our everyday choices, we'll avoid some serious messes in the future. I like simple.
I'm have no strong preference for either git or hg. TortoiseHG is a very convenient tool, in Windows. But, GitHub might prove more convenient with Android Studio itself, along with the connection to SourceForge.
Anyway. I'm going to experiment with the connection between GitHub and SourceForge a little more. See if I can get a little more comfortable with it.
P.S. I'm moving a little slower on this than I'd like. My air conditioner is out, so this room is a little uncomfortable. And, my development machine has blue screened a coupla times, I think due to heat. Depending on rain, it should get fixed sometime in the next few days.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm still leaning toward distributed. I like the idea of committing like crazy without worrying about how it affects anyone else before I'm finished with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jeje. It more or less summarizes my point, I could have written it myself.
Really, I do not mind using one or the other: we can even use it for our own training, if you feel that we can learn from using something new. I have never branched in GIT (neither even used HG) so maybe this is the moment to do it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It sounds like branching is part of what makes git so easy to use. Kind of like the difference between SourceSafe vs newer VCS. It took me a while before I was comfortable "just editing" a file without checking it out, first. With git, if you want to try a big experiment, go ahead and branch it. If it works, merge it back in. If not, delete the branch. And it never affects the other people. Far less planning and trauma involved than with svn.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In answer to your question about fixing minor bugs in Master.
If there was some reason we needed to get a new build out quickly, then we could make the change in Master. But, if there's no rush, then it's probably better to stay disciplined and make changes at Develop or lower. Otherwise, it sounds like we run a much greater risk of the hotfix not making it back down into Develop, and thus it accidentally gets backed out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have no experience working with a modern decentralized VCS in a multi-programmer setting. I think it would help me a lot if we nailed down some rules on how our high-level branching will work.
This article struck me as very straightforward. His examples are using the command-line version of Git. I haven't tried it, yet, but I think we can apply them direction to GitHub.
Apparently, this article has prompted plugins for git and GitHub called git-flow and GitHub Flow. It's unclear to me from the articles that I've read whether we need quite that much regimentation.
I think that while it's just the two of us, we should be able to do those steps manually. After we're a little more comfortable with the basic tools, we may find that the automation provided will be welcome.
Let me know what you think.
Have you considered using SVN? Both SF and AS natively supports SVN. One lees tool to admin and one less problem in the IDE. For a small project such a this, a decentralized repository such as GIT may be overkill.
Uhm, about branching.
I think we should stick to the-simpler-the-better-until-we-need-something-more-complicated. So I would start by a single trunk, and just tagging in every release, in case we need to fall back after a big problem. If later we feel that we need further branches, such as temporary branches for large developments (in the eventual case that we really made any large one), we can do it later.
Having lots of branches, such as the one in your first link is a must for large projects. For example, my current main-job project has around 100 developers and, right now, 3 different releases maintained at a time (an old version where we are releasing bug-fixing patches; a release candidate to be delivered this month; and the main long-run development), so that kind of complicated branching is absolutely needed (we have no less than 6 active branches right now, and a few more inactive). But for small projects such as this, I think it just causes lots of bureaucracy and failure-points.
Maybe I misunderstood your requests when you asked me to research and set up this open source system. One of the things you asked for was native support from Android Studio. The only cloud system that Android Studio supports natively is GitHub. But, if you're comfortable pushing and pulling from the cloud manually, then any of the popular version control systems will work with SourceForge.
We could drop GitHub entirely, and go straight to SourceForge. After setting up the system and connecting them, I'm a little less enamored with the convenience of GitHub integration in our situation. Going from there to SourceForge adds extra complication that outweighs the convenience in Android Studio. Using the VCS locally and manual pushing to SourceForge feels like it's going to be more straightforward.
As for which VCS to use, here are my thoughts that lead to my recommendation.
I have used SubVersion in the past. I was working by myself, so it was mainly just a way for me to be able to try stuff out without having to do the "copy everything to another directory" form of version control.
Since you have so much experience with svn, I can understand your reluctance to embrace branching. I had looked at branching in svn, but never felt comfortable actually doing that. It sounded like an advanced concept that required enough understanding and experience to plan ahead for it. I had read about some pitfalls if branches overlapped, especially in a distributed project. It just sounded like something to steer clear from.
Then, I read Joel Spolsky's tutorial on Mercurial. He brought up a few very common scenarios, even with just two people, that illustrated where svn falls down and requires manual merging. The distributed version control systems handle those situations in a much cleaner manner.
My understanding is that they actively encourage branching. Mostly because, they're merging repositories, and not just source files. That brings in a lot more information at the time of the merge, which helps make the merges smoother.
So, my vote would be pretty strongly for either Git or Mercurial. One thing I really liked about svn and hg was TortoiseSVN and TortoiseHG, that hooked into Windows Explorer. There is a (I think) fork called TortoiseGit. But, the description made it sound like it wasn't as mature as the others.
As for the branch naming rules. After reading those pages I pointed to, the main thing that I came away with was it greatly aids organization by being diligent about keeping Master always the last release. And, using Develop as a staging area prior to merging into Master for the next release.
Beyond that, I get the feeling that, with just the two of us, the rest of our branching can be a lot more relaxed, and just for our own personal organization. Even if we pick up a third programmer, chances are, we don't need to define anything any more rigid.
But, if we do find ourselves wishing we understood another guy's branches better, we can go back to those pages and incorporate some of those rules.
Please, do not consider this messages as command, but as advice based on my experience with both large and small projects, both corporate and open-source projects. Your experience may be as good as mine and your wish to work gives you the right to have the final decision.
Just take into account that AS does support SVN out of the box, only it is a bit hidden; see http://stackoverflow.com/questions/16679332/connect-android-studio-with-svn .
I have used SVN in a lot of projects (it is the VCS I use at home, because it is simple), but also have used other VCS, so I do not mind using others. My experience is that merging problems usually does not have to do with the VCS tool, but with the evolutions in the code itself, people forgetting to merge when needed and things like that. The tool eases or hardens the task, but is not usually them root of problems.
If you feel that two branches (Master and Dev) are a good idea, it is ok for me. Would you code minor bugfixings directly in Master? Or even bugfixing would be done in Dev?
I have just noticed that by default it is configured to use a command-line svn (File -> Settings -> Version Control -> Subversion). Just to test, I have configured it, against my own SVN server, by unclicking "Use command line client".
I do think of this as your project. You put in all the effort to get it working in the first place, and I want to respect that. And, you'll likely take back over primary control at some point. So, right now, I think your opinions do carry a bit more weight than mine.
Having said that, I am going to make one more push for git or hg, and then you can decide. If you greatly prefer svn, then I can accept that.
Just to give you a little more background on my experience with version control. I'm old enough that, when I started, cheap networks didn't exist. In the small teams I worked on, two to four programmers, we shared code on floppies. About once a month, someone would lose a day or two worth of work, when they copied the work of a colleague onto their machine.
Since then, I used a program for DOS called T-lib, between me and one other coder. Later, still in small groups up to about five or six, we were using SourceSafe. Systems that locked out your teammates while you were working on a particular file.
I worked briefly on one project that used CVS.
All of my experience with svn and hg has been on my own.
As I mentioned before, while trying to understand branching in svn, what I came away with was, Branching is Hard. aka It's easy to screw up and make a mess.
If you don't mind, I would like to ask your opinion of what Joel Spolsky says about Subversion. his contention that, because frequent check-ins pollute the repository with buggy code, that most Subversion users hold off checking in their code for days or weeks, until it's fully debugged. And, also, his "Subversion Story #1" about how hard it is to create and maintain a clean branch of the current shipping code.
Maybe you can give me some tips on how to avoid those two pitfalls? Or, point me at a page or two that you think do a good job of describing efficient ways of working with svn?
Last edit: Drake Christensen 2015-06-15
Is that written by Spolsky? Then I am temped to just agree without even reading it! I have learnt so many useful things from Spolsky (I almost every week recommend this or this to someone) that every word from his keyboard is to be carefully read.
I have read it and I almost completely agree with him. My only enhancement would be: even the best tool can be a mesh when used wrongly by a team that does not understand it; in such cases a worse-but-more-usual tool can lead to less problems. Actually, the same applies to design patterns, organizational structures, programming languajes and many other things.
If mercurial integration in SF and AS is simple, we can go for it. In the worst case, if we find later that the branching work takes long, we can change mind. I do not mind changing mind after testing it.
I have never used mercurial, but the branching (and local repository) concepts seem pretty similar to GIT (which I have used). And also, the notion of changeset is very similar to the one in MS Team Foundation Server (which is the one we are using in the large project that I described above).
Yeah, he's a sharp guy :-)
Git and hg are very, very similar. I've seen discussions of special cases where one is better than the other. But, for everyday use, they're conceptually identical.
Spolsky's company Fog Creek even has a service called Kiln, that provides a repository that both git and hg can talk to. One developer can use git and another hg, both on the same repository.
And, like you, I have enough experience to know that any tool can be misused. That's why I was wanting to nail down some minimal rules on the branching stuff. I think if we stick to a couple of simple rules to guide our everyday choices, we'll avoid some serious messes in the future. I like simple.
I'm have no strong preference for either git or hg. TortoiseHG is a very convenient tool, in Windows. But, GitHub might prove more convenient with Android Studio itself, along with the connection to SourceForge.
Anyway. I'm going to experiment with the connection between GitHub and SourceForge a little more. See if I can get a little more comfortable with it.
P.S. I'm moving a little slower on this than I'd like. My air conditioner is out, so this room is a little uncomfortable. And, my development machine has blue screened a coupla times, I think due to heat. Depending on rain, it should get fixed sometime in the next few days.
Just to add to the confusion, the top reply is a very balanced analysis of svn vs git.
I'm still leaning toward distributed. I like the idea of committing like crazy without worrying about how it affects anyone else before I'm finished with it.
Jeje. It more or less summarizes my point, I could have written it myself.
Really, I do not mind using one or the other: we can even use it for our own training, if you feel that we can learn from using something new. I have never branched in GIT (neither even used HG) so maybe this is the moment to do it.
I do enjoy learning new things.
It sounds like branching is part of what makes git so easy to use. Kind of like the difference between SourceSafe vs newer VCS. It took me a while before I was comfortable "just editing" a file without checking it out, first. With git, if you want to try a big experiment, go ahead and branch it. If it works, merge it back in. If not, delete the branch. And it never affects the other people. Far less planning and trauma involved than with svn.
In answer to your question about fixing minor bugs in Master.
If there was some reason we needed to get a new build out quickly, then we could make the change in Master. But, if there's no rush, then it's probably better to stay disciplined and make changes at Develop or lower. Otherwise, it sounds like we run a much greater risk of the hotfix not making it back down into Develop, and thus it accidentally gets backed out.