Version control system recommendation?

[turtles]

I want to try out a few new vcs's and am looking for recommendations for our work flow thanks.
I(we) have the following set up:

[eyoung100]

Before you throw out Git, have a look at the manual and step by step book. Git does allow SSH checkout:
Git - Documentation
_________________
The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper

[Maitreya]

Before I used GIT I was familiar with most of the SCM's out there and was used to their flow.
This made GIT very confusing for me at first. Now however when I've bent my head around the GIT concept I don't want anything else.

http://www.youtube.com/watch?v=4XpnKHJAok8
Lengthy biased, but very informative.

The merrits of having it distributed is just worth it.

[666threesixes666]

git is tough to understand at first.... because you build the revisions on a local machine and don't need a server.

its like build a little bit, save progress build a little more save progress build to finish save progress. 3 git revisions local, then push to server git server tracks the 3 revisions also. it basically clones the repository you've built.

gitlab wiki is a mess, they update that software way too much. the overlay is very out of date.

gitlab will manage all users ssh keys and give them push pull access easily. id keep the server nested deep in the network far away from any malicious attackers, then make the check out only static versions of finished product.

[1clue]

I'm still what I consider to be a git novice, but these courses helped me understand a lot better:

Free:
http://try.github.io/levels/1/challenges/1

Paid, but first course is free:
https://www.codeschool.com/courses/git-real

My company has gone through several SCM products starting with CVS and including subversion and git. Before that I used several commercial tools. Git is the clear winner.

The thing about git that threw me off is the local repository. It sounds like a big pain, but it gives you a huge amount of control. You can also commit your local branch as a branch on the remote repository, and it's easy.

I won't recommend anything else. I have neither seen nor imagined a scenario git can't handle better than any other tool we've used.

Git's biggest strength is its branching and merging capabilities. Give yourself a weekend, work through every tutorial you can find and practice it on a copy of your code. Or on a sample project.

[schorsch_76]

I can only reassure what 1clue wrote. git has such big amount of usecases. its unbelivable.

[toralf]

git

[turtles]

Ok Wow 4 unanimous votes for git.

My head is not wrapping around how would a co-worker get my changes if I hoard them on my laptop?
I trust you all there is a way around this.
a coworker can ssh into the server and I can ssh into the server but he wont want to try to figure out how to ssh in to my laptop where ever I am.
I figured out git-svn because the main project is in svn we have to svn update from the "main" repo daily.
So our git master will be changing daily.

Ok now the docs say to push my changes back to the main repo but the repo is "checked out" so I imagined it would not like that.
just to see I checked out or "cloned" the master from the server to my laptop made some changes and tried to push it back to master. (svn style)

[toralf]

IRC: #git

[1clue]

A coworker who hoards changes is not a coworker. They're a problem which needs solving, possibly by replacement.

There is no SCM which can get around this.

I just watched that Linus Torvalds@Google YouTube video. I'm struck yet again how this guy has no issues with self confidence.

Git works extremely well in ways that encourage proper sharing.

You might choose a central repository (github for example, or ANYTHING else) for the "official" repository. Git has no dependency on any central repository, and the Linux kernel has none.

You as a developer update when you want from sources you trust. You have a "master" branch which you traditionally want to keep clean. You branch for a project (say, new_toolbar), you make changes, you commit as soon as you finish even the tiniest unit of work that makes sense. You might share that branch with others, who might submit changes back to your branch. When you have a working, tested feature with all tests passing, you would merge that back to your master, and then push it out to the remote repository.

Likewise "your" branch could be on the remote repository to which you and a few others might have write access, but not to the master branch. You'd have a branch called new_toolbar or whatever and everyone working on that would pull from that, make their changes and push back when they have something worth committing.

By convention, the master of any repo is limited to working code with all tests passing, and more importantly all tests have been executed. Which means anyone who has access can read from that repo and get working code.

[1clue]

Sorry, can't stop.

The problem with other SCMs is that branching and merging is very difficult and fraught with problems.

git handles branching/merging really well, and everything is fast. In fact, if you download (clone) a repo, you have automatically branched by any standard. From there you can branch and merge to and from your local repo, and then push all or some of it back to the remote as you decide.

That said, if you have people hoarding code you need to fix it. That's a behavioral problem, not a thing you can fix with a tool. The longer you wait between commits, the less likely the commit will be clean and the less likely it will go well or be well documented.

For teammates working on a single feature like new_toolbar, a lot of coordination is needed and frequent updates are critical. You need a scenario where you can make changes and commit them whether they work or not, whether they're tested or not. Somebody else might depend on the interface you're developing, so even stubbing something out is committable.

For other teams on the same repo, they only want to see a fully functional, fully tested new_toolbar. That's where the master branch comes into play.

[turtles]

[666threesixes666]

git -> git is how your co worker gets the changes. or you can use gitlab as a central git repository. git > gitlab > co-worker git... yes hoarding changes are a problem.... its a mass patch system. code checked out, worked on, changes merged to master git repo.... if they cant handle that, then they need a brain transplant. you dont push, master pulls. you offer your godlike patches, master approves or disapproves.

[turtles]

[eyoung100]

For a proper working example, see The ChromiumOS Project. The Master Branch is Open to the public, but requires each user to sign up, and if contributing code you must follow these guidelines.

This model may require you to update your standards and practices in order to prevent "code hoarding." While this may seem like a PITA in the short run, you will thank us later...
_________________
The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper

[turtles]

[666threesixes666]

as far as i know yes, ive only scratched the surface of git though.

[turtles]

Well thats a problem.
So I am behind a firewall I have no control over on a laptop. I cant open ssh port on the firewall and allow the remote server to "pull" from my laptop.
_________________
Donate to Gentoo

[schorsch_76]

On the server you need a bare repository. So you can push to it. The clients pull from it. Here is a successfulgit development model [1]

[1] http://nvie.com/posts/a-successful-git-branching-model/

[666threesixes666]

i only know fork and pull... i guess there is a shared repo model. you'd really need to ask them, i only know gits designed much better than svn and cvs. mercurial & bazzar im not sure about.

https://help.github.com/articles/using-pull-requests

[eyoung100]

[eyoung100]

[1clue]

[eyoung100]

[turtles]