Advertising (This ad goes away for registered users. You can Login or Register)

revision control system tips

Programming on your favorite platform, for your favorite platform? Post here
Post Reply
User avatar
Xian Nox
Retired Mod
Posts: 2749
Joined: Fri Nov 05, 2010 5:27 pm
Location: Over the hills and far away

revision control system tips

Post by Xian Nox » Mon May 13, 2013 8:48 am

So, I've been using mercurial for a while, and I believe I have benefited from it greatly. Tracking changes, synchronizing source code between different PCs/OS's, as well as the ability to check previous revisions for source code I have removed only to break stuff have been a godsend.
For being a self-taught user of drcs/mercurial, I cannot help but feel like I'm missing stuff I can be doing, and I also lack the experience of working in teams consisting of more than 2 users. Any tips, experiences and articles on the matter you can share are welcome.
Advertising

svenn
Posts: 65
Joined: Fri Dec 24, 2010 5:17 pm
Location: Belgium
Contact:

Re: revision control system tips

Post by svenn » Mon Jun 10, 2013 2:58 pm

I think its like program languages, once you get hooked, its hard to change to something different; I have used SVN and I like it cause its integration in windows & notepad++ is good; On professional level I need to work with darcs (its old) which is oké. I also tested with GIT, but I think its counter-intuitive, but many, many find it "tha bomb". I wonder how bigger teams manage it, I have no team-programming experience. So ill be tracking this topic aswell 8-)
Advertising

User avatar
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

Re: revision control system tips

Post by m0skit0 » Mon Jun 10, 2013 8:22 pm

Mercurial? SVN (please, update that sh*t) :lol: ? Git FTW!

Anyway I think Mercurial is compatible with Git and SVN repositories (but not the other way around). I tried it very little time but it's not very different from Git. SVN is a little outdated now and most likely will disappear due to the lack of some powerful features and flexibility in new tools. For example, distributed work (e.g. you can commit your work offline and push it to the server later), stashing, soft/mixed reset, SSH, bare repositories, faster, much smaller size repositories (sometimes around 90% smaller...), branches carry the whole history...

My team is comprised of myself + 2 developers that work in same office as I do + 3 developers that work from China.

IMHO to work with more than 3-4 people I suggest a central repository with at least a development and a master (or production) branch. Everyone should develop and push (or whatever you call it in hg ;) ) under the development branch (and any local branches they want to create, of course, but of course no pushing these to the central repository) but only one (or 2, depending on the commiters size) should merge development with master to get the release version. I also suggest the central repository to be in the cloud (e.g. GitHub, Google Code, Sourceforge, etc...). This is how I choose to set up this at work. Oh and any thoughts about this setup are also welcome! :)
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"

User avatar
Xian Nox
Retired Mod
Posts: 2749
Joined: Fri Nov 05, 2010 5:27 pm
Location: Over the hills and far away

Re: revision control system tips

Post by Xian Nox » Mon Jun 10, 2013 9:10 pm

Well, when I tried using vcs in general, I found mercurial to be the easiest to understand. Had quite a bit of trouble there. :lol:
Mercurial is compatible with Git, yes, there's the hg-git plugin, which gives it support for pushing/pulling from those. I've used it to clone some github repositories, and it worked out rather well. There appears to be a svn plugin as well.
m0skit0 wrote:IMHO to work with more than 3-4 people I suggest a central repository with at least a development and a master (or production) branch. Everyone should develop and push (or whatever you call it in hg ;) ) under the development branch (and any local branches they want to create, of course, but of course no pushing these to the central repository) but only one (or 2, depending on the commiters size) should merge development with master to get the release version. I also suggest the central repository to be in the cloud (e.g. GitHub, Google Code, Sourceforge, etc...). This is how I choose to set up this at work. Oh and any thoughts about this setup are also welcome! :)
Okay, here's a question: what's the point of not pushing the local development/testing branches? Also, what do you do in git to mark them to not be pushed? Apart from that, the more I think about this setup, the more it makes sense.
And cloud repositories are so good after file system corruptions or mistake formats. I've also found them incredibly useful for synchronizing code between Linux and Windows on a dualboot because of no proper ext4 drivers. Which brings me to another most likely newbie question: when is the proper time to commit code? I mostly do it when I find the changes made are significant enough (for which I have no actual definition), or when I need to test on the other OS. Does commit size even matter?

User avatar
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

Re: revision control system tips

Post by m0skit0 » Mon Jun 10, 2013 9:59 pm

Xian Nox wrote:what's the point of not pushing the local development/testing branches?
Because that's a developer local work. There he can try new stuff and such things. This is not needed in the central repository. If some other dev B wants to check this dev A work, he can simply pull that branch from him/her. No need to confuse things in the central repository level, let alone branch naming conflicts and such.
Xian Nox wrote: what do you do in git to mark them to not be pushed?
Branches that have no remote configuration cannot be pushed anywhere ;)
Xian Nox wrote:I've also found them incredibly useful for synchronizing code between Linux and Windows on a dualboot because of no proper ext4 drivers.
I use NTFS for that, because sometimes I might be offline.
Xian Nox wrote:when is the proper time to commit code? I mostly do it when I find the changes made are significant enough (for which I have no actual definition), or when I need to test on the other OS.
I think you mean pushing to the remote server, am I right? That's up to the developer or the accorded protocol. Same goes for local commits (in Git these local commit will simply be pushed to the remote repository -and meged if fast-forward is enabled, though I don't recommend activating fast-forward pushes if you don't know what you're doing like me :lol: - ).
Xian Nox wrote:Does commit size even matter?
I never heard anything about that, so I guess it does not. Might be a problem if you're trying to push too much/too large commits over a slow/unstable network.

Oh and btw Git also has cherry-picking, where you can pick individual commits to be applied to your current code as new commits. Oh and stashing. This feature only deserves using Git.

EDIT: oh, and rebase or merge branches... And you can learn Git without even having to install it ;)
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"

User avatar
Xian Nox
Retired Mod
Posts: 2749
Joined: Fri Nov 05, 2010 5:27 pm
Location: Over the hills and far away

Re: revision control system tips

Post by Xian Nox » Mon Jun 10, 2013 11:41 pm

m0skit0 wrote:Oh and btw Git also has cherry-picking, where you can pick individual commits to be applied to your current code as new commits. Oh and stashing. This feature only deserves using Git.
Hmm, hg graft is supposed to be similar to cherry-picking, but is not something I'm overly familiar with. Stashing on the other hand feels like hg revert --all, if I understand it correctly. What revert --all does is revert the changes done to all tracked files, and keep the modified files but give them a .orig extension. Though reading more into it, it looks like you can get multiple stashes, which can definitely be useful.
m0skit0 wrote:EDIT: oh, and rebase or merge branches...
Reading on rebasing, I came across yet another git/hg comparison, and explanations on how git allows changing history, and mercurial doesn't. Actually, what advantages does changing history give?
m0skit0 wrote:And you can learn Git without even having to install it ;)
Fun little tutorial, wish I found it earlier.

User avatar
codestation
Big Beholder
Posts: 1660
Joined: Wed Jan 19, 2011 3:45 pm
Location: /dev/negi

Re: revision control system tips

Post by codestation » Tue Jun 11, 2013 5:30 am

Xian Nox wrote: I cannot help but feel like I'm missing stuff I can be doing,
Like bisect? Read about it if you haven't yet, it can help you to save much time when you find regressions on your code and need to locate the faulty commit.
Xian Nox wrote:Any tips, experiences and articles on the matter you can share are welcome.
Since i am a git user i have two articles that helped me to design a better workflow for my projects:

A successful Git branching model
Understanding the Git Workflow

Before reading these i just used the master branch or used an alternate one then randomly merged the two. Personally now i am using a mix of the two models: I work on the dev branch most of the time and use feature branches when i need to implement a big change. I never commit to the master branch directly, instead i merge the dev branch on master when is stable enough to be used in production.

The second article talks about the consequences on --no-ff (who is the basis of the first article) and goes for another approach that looks better IMO for managing the commit history. Of course, you are free to choose your preferred workflow style.
Plugin list
Working on: QPSNProxy, QCMA - Open source content manager for the PS Vita
Playing: Error: ENOTIME
Repositories: github, google code
Just feel the code..

User avatar
m0skit0
Guru
Posts: 3817
Joined: Mon Sep 27, 2010 6:01 pm

Re: revision control system tips

Post by m0skit0 » Tue Jun 11, 2013 11:44 am

Xian Nox wrote:it looks like you can get multiple stashes, which can definitely be useful
Also you can apply the stashed changes to any branch, not only the original were you were working ;)
Xian Nox wrote:what advantages does changing history give?
The possibility to change the branch history? :lol:
codestation wrote:A successful Git branching model
Understanding the Git Workflow
Read those too :mrgreen: Excellent articles indeed.
codestation wrote:I never commit to the master branch directly, instead i merge the dev branch on master when is stable enough to be used in production.
Yup, exactly as I planned it at work ;) Just in my case, there's only one guy responsible with the merge.
I wanna lots of mov al,0xb
Image
"just not into this RA stuffz"

Post Reply

Return to “Programming”