Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Version control system recommendation?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
eyoung100
Veteran
Veteran


Joined: 23 Jan 2004
Posts: 1411

PostPosted: Tue Nov 12, 2013 10:53 pm    Post subject: Reply with quote

turtles wrote:

I was looking at that last night. I don't get what the colors mean in his post and the lines are they each a repo?
Reading it again now...
Say we have a 3 developer shop.
Here ill change that diagram up, now each dev would be a colored dot in his diagram and works from home or whereever.
There is a server somewhere where everyone can get in to, but as the integrator of master you cant pull from everyone's repo back to the server due to firewalls and non static ip's. So I don't get how we are making a new master?
Here is what it looks like to me:
http://postimg.org/image/pziuihd1t/



STOP AND SLOW DOWN. Your photo is totally WRONG :!: You cannot mix the developers with the Branches. Not to sound harsh, but you seem to be in a hurry, and the concepts here use sound programming principles, that take awhile to get used to

Study this photo instead. You will never be able to checkout developer A or B's code regardles of Where they are.

Developer A clones origin.
Developer B clones Origin.
They each receive the entire copy of origin as a local repository.

Developer A works on Feature A, the Pink Line
Developer B works on Develop, the Yellow Line

Developer A Contacts you via email and says Feature A is ready, and sends you the link to his local Repo(within your firewall), you merge Developer A's Feature into Developer B's Yellow Developer Line, and tell Developer B to repull from developer. Developer B now sees Developer A's changes in his local repo. If he was inadvertently working on developer A's feature, Developer B will receive a Fix request in his local repository(because his fix to feature A doesn't match what you approved). This helps with delegating tasks.

If Developer B was following Directions and only working on develop, and finishes, after repulling the new change from developer A, he will contact you via email and say please merge my changes in develop with the master(blue dots). You will merge Develop into Master, leaving origin untouched.

Developer A and B will repull master.

After all having new masters they start on the next task.

After Bugtesting Developer A's Feature and Developer B's change to master, if you approve, ie everything works, you will push master to origin, and tell developer A and B to submit the next changes

Developer C gets hired on and has no local Repo, he clones from origin, which contains all the work that Developer A and B have already done and creates his own local repo.

Each dot in the diagram is a branch pull, ie when you tell Developer A and B to repull they will each create a blue dot.

Edit: Based on 1clue's post, changed pull to clone where applicable. All other edits were spelling related.
_________________
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


Last edited by eyoung100 on Wed Nov 13, 2013 2:27 pm; edited 8 times in total
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1370

PostPosted: Tue Nov 12, 2013 11:12 pm    Post subject: Reply with quote

turtles wrote:
Yeah thats why git having it all on my laptop is a problem, and making branches people wont know about is a problem. Were all over the place not in an office my team mates cant get to my laptop it needs to be on a server.
svn has worked for well for me for years, never had a server die or fail without a mirror or any of that.

Still reading the stuff from above ;)


Sorry for a second post on the same comment.

With cvs or subversion there is a single master which contains all the information. If the server dies you've lost data, and if you have no backups then you're screwed.

With git, everyone who clones the project has everything they need to set up a new server, accurate until the point in time when the repo was cloned or last pulled. Every laptop or workstation is a full backup. If you're spread all over the world, then even the destruction of a continent by an asteroid will not lose your data.
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1370

PostPosted: Tue Nov 12, 2013 11:18 pm    Post subject: Reply with quote

eyoung100 wrote:

Quoting the site I gave earlier:
Quote:
The integration work flow model
Git supports several different work flow models and most corporate environments adopt the integration manager model – where a single person is responsible for all the commits to the “blessed” repository.

Developers clone from this blessed repository when needing to work on the project, pushing their changes back to their own independent repositories, asking the integrator to pull in their changes for approval and inclusion into the next release.


As a developer you don't work on the "blessed repo," you check it out, work on it, submit your changes to your independent repo, then ask the integrator to approve your change, and upload for you. After that your changes are seen by everyone. Even the integrator pulls the blessed repo into his local repo. The only difference is that in some companies the integrator doesn't have to ask for permission to push his changes. In your case, you would be considered the integrator.


All this does is enforce a monolithic central repository on software which has no need for it. It also places all the load for a reliable official working copy on a single person, which IMO is ridiculous.

If you're going to have a central authoritative repo, it makes sense to have a team who can commit to a central repo, as many (including me) do with github. That's really only necessary because we all work from laptops and nobody is always on line to get all the commits.
Back to top
View user's profile Send private message
eyoung100
Veteran
Veteran


Joined: 23 Jan 2004
Posts: 1411

PostPosted: Tue Nov 12, 2013 11:24 pm    Post subject: Reply with quote

1clue wrote:


All this does is enforce a monolithic central repository on software which has no need for it. It also places all the load for a reliable official working copy on a single person, which IMO is ridiculous.

If you're going to have a central authoritative repo, it makes sense to have a team who can commit to a central repo, as many (including me) do with github. That's really only necessary because we all work from laptops and nobody is always on line to get all the commits.


I understand where you're coming from but the OP made it seem like that by "hoarding code" that someone was in charge, which lends itself to the monolithic model.
_________________
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
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1370

PostPosted: Tue Nov 12, 2013 11:55 pm    Post subject: Reply with quote

Let's slow down a bit.

Git was made by Linus Torvalds, who (if you didn't know) was the same guy who started the Linux kernel. He made it specifically with the kernel in mind, and he also mentioned in that youtube video that it's used on projects with a quarter million files. Don't think that's the kernel, but the kernel has hundreds or thousands of developers, not all of whom Linus trusts.

Git is designed such that each checked-out repo is a complete repo, with history and everything. It is, in effect, a complete backup of the repo, so if your "official server" goes down and you have 14 developers, then you have 14 backups of what was on the official server.

eyoung100 is exactly right on everything, except that when you "check out" a project from a remote, you use "git clone" rather than "git pull."

I think it would be a really good idea to go through one or several git tutorials. If you feel like you need a central repository, then maybe the github one would be a good idea. They take a lot of the harder administrative stuff out for you, let you focus on developing.

One thing I think the OP is having trouble with is that of access to developer workspaces. That's just not how it typically works, and I would call it a huge problem. When I clone a repository to my laptop, I'm the only one with access. Period. The same is true for all the other developers.

I can, on my local copy, branch off of the master for my own development. If I'm the only one who is working on that feature, then nobody else needs to have or see that branch. I commit regularly as I go, and don't need to worry about whether anything works or not. Meanwhile, I could pull from my local master as many times as I want, and it's not tarnished by my local development. When I get it working and tests passing, I can merge it to my local master and retest before committing (to local), and then I can push my changes to the central public repo with "git push."


What other people are saying about "master pulls" is when not all developers have write access to the central repo. It seems to me that the OP is working on a small team, and it's reasonable that they all have write access to the server.
Back to top
View user's profile Send private message
wjb
Guru
Guru


Joined: 10 Jul 2005
Posts: 353
Location: Fife, Scotland

PostPosted: Wed Nov 13, 2013 1:07 am    Post subject: Reply with quote

Take a look at "Hg Init: a Mercurial tutorial" by Joel Spolsky. I think its a nice simple explanation of the principles of any dvcs.
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1237
Location: 42.68n 85.41w

PostPosted: Wed Nov 13, 2013 1:48 am    Post subject: Reply with quote

http://wiki.bazaar.canonical.com/BzrVsGit#Windows_Support bazaar is more doze friendly if you're the pc god and they are the devs. just sayin. thats all i know about bzr.
_________________
cat /etc/*-release
Funtoo Linux - baselayout 2.2.0
consider this warning no. 1
https://wiki.gentoo.org/index.php?title=Special:Contributions/666threesixes666&offset=&limit=500&target=666threesixes666
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1370

PostPosted: Wed Nov 13, 2013 1:49 am    Post subject: Reply with quote

Looking at that youtube video from early in this thread, I see a lot of really pertinent points starting right around 10:50, maybe a little earlier. Here's what I got from it:


  1. Linus started with tarballs and patches for revision control.
  2. He hates CVS and SVN, has never used them for the kernel but did use CVS while working for a company.
  3. He went to BitKeeper for awhile, and this is what convinced him that a SCM was worth using.
  4. He used three criteria to find a satisfactory SCM, and that basically eliminated everything available. See later.
  5. He wrote git in two weeks, and it was better than anything else available.


Three criteria:

  1. Must be distributed.
  2. Must be fast.
  3. What you get out MUST BE EXACTLY what you put in, or you get an error.


The first two I can understand, but the last one is crazy. Most revision control systems evidently don't detect corruption. I've seen it myself with both cvs and svn: The first clue that there is corruption is that your code won't compile. You fish around and discover that the file is borked.

I seriously recommend that video, even though I gave it a thumbs up before.
Back to top
View user's profile Send private message
Yamakuzure
Veteran
Veteran


Joined: 21 Jun 2006
Posts: 1375
Location: Bardowick, Germany

PostPosted: Wed Nov 13, 2013 4:05 pm    Post subject: Re: Version control system recommendation? Reply with quote

turtles wrote:
Git has been recommended to us but we are required to keep our work on the server for others to checkout.
Then, and according to the chart you drew, you want git.
Migrate to git. Now. It is simple, fast and easy!

You can have a git server, and it is dead simple to set up. See: set up a git server through an ssh connection.

cgit is a hyperfast web frontend that is just bloody brillant.

This is all too small? Big corporation? gitolite or a corporate account on github might be *the* thing you need.

I have been some sort of "Subversion Zealot" for many years. Subversion is just great. But after working with git a couple of years now, I do not understand how I could ever work with a non-distributed VCS like Harvest, CVS or SVN.
1clue wrote:
The first two I can understand, but the last one is crazy.
Hash Checksums.
_________________
I *do* know that I easily aggravate people due to my condensed writing. Rule of thumb: If I wrote anything that can be understood in two different ways, and one way offends you, then I meant the other! ;)
Back to top
View user's profile Send private message
schorsch_76
Apprentice
Apprentice


Joined: 19 Jun 2012
Posts: 207

PostPosted: Wed Nov 13, 2013 5:52 pm    Post subject: Reply with quote

May i give you an overview how i work with git on a projekt.

First the initial checkin:
Code:
git init
git add *
git commit -a -m "Initial commit"


Now you have a git repository. It contains all your added files on branch master. Now lets setup the described development model.

Code:
git branch develop

All done. Now let's setup the bare repository for the server.

Code:
cd ..
git clone --bare myproject


This is now the folder which is put on the server. Its the central part of your model.

Now clone from the server the working repository.

Code:
git clone https://my-server/my-path.git


Now you have in your repo both branches master (which only holds releases) and develop (where develoment work like merging is done).

Now checkout develop
Code:
git checkout develop


Here you can do your work. For bigger features i create a branch like
Code:
git branch feature/cool-feature
git checkout feature/cool-feature


After you have done your work, add files and commit them to feature/cool-feature. Test it and so on.

now merge it to develop

Code:
git checkout develop
git merge --no-ff feature/cool-feature


Now all your work is on branch develop. You polish your work and merge it to master if its ready

Code:
git checkout master
git merge develop
git tag v1.0


It is all in your repository. Not yet on the server. Lets push it to the server
Code:
git push origin master
git push origin develop
git push origin --tags


Your working branch feature/cool-feature can now be deleted or be kept. Depending on what you want to do. Your co-workers can get your changes form the server like this:

Code:
git fetch origin


all data is now available to them, but their branches develop and master are behind the server. To pull them forward, they can do the following:
Code:
git checkout develop
git merge origin/develop


If they made changes to the develop branch, they merge it. If your changes dont interfer with your changes, git will do the work. If it encounters problems, you need to resolve them.

you can add other remotes like origin, like bob or alice. and keep all data in your repository. Merge bob's changes locally to your develop branch and so on.

It's only your definition, that the server is the most relevant part. There is no "right" or "wrong" repository. All are equal. It's only definition, that linus linux-2.6.git repo is the most important repo for linux.

Hope that this did clearify some things for you.

[/code]
Back to top
View user's profile Send private message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1234

PostPosted: Wed Nov 13, 2013 9:50 pm    Post subject: Reply with quote

ok eyoung100 I slowed down :)

still all your reading all the recommended git stuff ....
Thanks for staying with me.
I quit watching the video as soon as linus said "this is not a tutorial on git if you want that there is this thing called google"
I have definitely got git set up now on the server (Gentoo of course)
and can use it with ssh keys.


AHHH HA a "bare" repository is what I was missing! Thats a repo on the server we can all push to.
Now I don't have to worry about being code hoarder.
I was just getting to that on http://gitbyexample.org/
which is the best so far for my needs.

schorsch_76 wrote:

All done. Now let's setup the bare repository for the server.

Code:
cd ..
git clone --bare myproject


This is now the folder which is put on the server. Its the central part of your model.

Now clone from the server the working repository.

Code:
git clone https://my-server/my-path.git


Now you have in your repo both branches master (which only holds releases) and develop (where develoment work like merging is done).

Now checkout develop
Code:
git checkout develop


Here you can do your work. For bigger features i create a branch like

[/code]


I owe you all a beer.
_________________
Donate to Gentoo
Back to top
View user's profile Send private message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1234

PostPosted: Wed Nov 13, 2013 10:11 pm    Post subject: Reply with quote

So from what I am reading
the bare repo will be on a server with a static ip that we all can get to easily.
it will work like this:

Code:

 +------------+      can push and pull
 | Developer A|+---------+
 |------------|<--------++
 | Has Master |         ||
 |& Devel and |         ||
 |has the bare|   +-----|v--------------------------------------+
 |as remotes  |   |+----+-----------+       +----------------+  |
 |            |   || "Bare" repo dir|       | Main repo Dir  |  |
 +------------+   ||----------------|  git  |----------------|  |
                  ||Has a master    |<-----+|This repo pulls |  |
                  ||And develop     |       |git-svn from the|  |
                  ||                |       |main project    |  |
                  ||                |       |  (upstream)    |  |
                  ||Is on server    |       |Has the "Bare"  |  |  git-svn
                  ||                |       |as remote       |<-----------+
                  |+----------------+       +----------------+  |  https  |
                  |    + ^                                      |         |
                  |    | |   this is a static domain            |         |
                  +----|-|--------------------------------------+         |
  +--------------+     | |                                                +
  |Developer B   |     | |                                     +------------------+
  |--------------|     | |                                     |up stream project |
  | has master & |     | |                                     |------------------|
  |Devel and has <-----+ |                                     |They use svn      |
  |the bare as   +-------+                                     |                  |
  |remotes       |                                             |                  |
  |              |                                             |                  |
  |can be anywher|                                             |                  |
  +--------------+                                             +------------------+

Where there will be two directories on the server each with a git repo
one will be a bare and one will slurp up the new stuff from the upstream project?
developers can "push" incomplete or feature branches back to the "bare"
New stuff from upstream will need to be merged into the bare. - I think
_________________
Donate to Gentoo
Back to top
View user's profile Send private message
eyoung100
Veteran
Veteran


Joined: 23 Jan 2004
Posts: 1411

PostPosted: Wed Nov 13, 2013 11:09 pm    Post subject: Reply with quote

turtles wrote:
So from what I am reading
the bare repo will be on a server with a static ip that we all can get to easily.
it will work like this:

Code:

 +------------+      can push and pull
 | Developer A|+---------+
 |------------|<--------++
 | Has Master |         ||
 |& Devel and |         ||
 |has the bare|   +-----|v--------------------------------------+
 |as remotes  |   |+----+-----------+       +----------------+  |
 |            |   || "Bare" repo dir|       | Main repo Dir  |  |
 +------------+   ||----------------|  git  |----------------|  |
                  ||Has a master    |<-----+|This repo pulls |  |
                  ||And develop     |       |git-svn from the|  |
                  ||                |       |main project    |  |
                  ||                |       |  (upstream)    |  |
                  ||Is on server    |       |Has the "Bare"  |  |  git-svn
                  ||                |       |as remote       |<-----------+
                  |+----------------+       +----------------+  |  https  |
                  |    + ^                                      |         |
                  |    | |   this is a static domain            |         |
                  +----|-|--------------------------------------+         |
  +--------------+     | |                                                +
  |Developer B   |     | |                                     +------------------+
  |--------------|     | |                                     |up stream project |
  | has master & |     | |                                     |------------------|
  |Devel and has <-----+ |                                     |They use svn      |
  |the bare as   +-------+                                     |                  |
  |remotes       |                                             |                  |
  |              |                                             |                  |
  |can be anywher|                                             |                  |
  +--------------+                                             +------------------+

Where there will be two directories on the server each with a git repo
one will be a bare and one will slurp up the new stuff from the upstream project?
developers can "push" incomplete or feature branches back to the "bare"
New stuff from upstream will need to be merged into the bare. - I think


You miss the last point. Once Bare is pushed to, it is no longer bare, it becomes a branch or repo on it's own. Other than that you've got the idea :D
_________________
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
Back to top
View user's profile Send private message
schorsch_76
Apprentice
Apprentice


Joined: 19 Jun 2012
Posts: 207

PostPosted: Thu Nov 14, 2013 6:27 am    Post subject: Reply with quote

If you do your work on a upstream project, you can adjust the development model. Add a branch upstream. Start all branches master/develop/upstream at the same commit. You merge upstream to develop, do stuff, merge to master and make your release. If upstream has a new release, you can update the upstream branch with that data commit it , tag it like upstream/v0.9.8, and merge it to develop. Git will do the merging. If there are conflicts resolve them. All your changes are the changes from the new upstream release are now on your develop branch and behave like expected.

If you started development branches from develop prior to the merge of the new upstream release, rebase your local feature/cool-stuff to the new head of develop. All changes will then be in your rebased branch feature/cool-stuff. Including all changes from the new upstream release. An other method would be to merge develop to your feature/cool-stuff branch.

This is basically a method with is used by debian package maintainers. There is one drawback. DONT REBASE PUBLISHED BRANCHES!!! Never ever!!!. Your co-workers would hate you! Rebase can be substitued by merging but is sometimes more convienient than merging.

Edit: You update upstream branch locally and push it like normally to the server.

Bye
schorsch
Back to top
View user's profile Send private message
Maitreya
Apprentice
Apprentice


Joined: 11 Jan 2006
Posts: 220

PostPosted: Thu Nov 14, 2013 11:05 am    Post subject: Reply with quote

However that the video is not a tutorial it will show you WHY you should not see it as a drop-in replacement for your current workflow. So please watch the video and take the advice the others gave instead of fitting the GIT idea into you current way of thinking. Fit your current way of thinking into GIT.
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1370

PostPosted: Thu Nov 14, 2013 8:42 pm    Post subject: Reply with quote

Maitreya wrote:
However that the video is not a tutorial it will show you WHY you should not see it as a drop-in replacement for your current workflow. So please watch the video and take the advice the others gave instead of fitting the GIT idea into you current way of thinking. Fit your current way of thinking into GIT.


+1 on that.

Most workflows are designed around the limitations of the tools available. Git is designed in a way that most of the organizational limitations don't exist. The video shows Linus expressing that wonderfully. He trusts a handful of people, each of whom trust a handful of people. Some of each of those handfuls intersect, but eventually you get to the hundreds or thousands of developers who contribute regularly to the Linux kernel. Each person puts out pull requests to his/her friends with new changes, they integrate into their own version and test accordingly. The changes don't pass through the entire universe of developers as fast, but each change gets more testing this way.

Edit:

I forgot the point. :)

Anyway, if git can handle that sort of a non-structural arrangement, then it can certainly adapt to pretty much anything you might want. It might be really beneficial to you and your coworkers to come up with something that makes the most sense for you.

If everyone is always on laptops and the lids aren't all open at the same time, then you might want a central server. Otherwise, you might not actually need one.
Back to top
View user's profile Send private message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1234

PostPosted: Fri Nov 15, 2013 1:18 am    Post subject: Reply with quote

Thanks again all I will refer to this thread often.
Did I mention I owe you all a beer?
_________________
Donate to Gentoo
Back to top
View user's profile Send private message
miket
Apprentice
Apprentice


Joined: 28 Apr 2007
Posts: 205
Location: Gainesville, FL, USA

PostPosted: Fri Nov 15, 2013 8:00 am    Post subject: Reply with quote

Sorry that I'm getting into this thread kind of late.

I'm putting in a good word for Mercurial. It has a lot of similarities to Git (distributed version control, designed by a kernel developer, cryptographically signed commits, supportive of central repositories, introduced at basically the same time), but it's a *whole* lot friendlier to use.

I've suffered through CVS and Subversion; I'd never want to go back to those--not even for the "benefit" of a central repository. Having the whole repository right there in your checkout is the way to go! I'd sure slog through Git before I'd go back to one of those server-based systems, but I'd much rather do it with Mercurial.

The Mercurial tutorials already mentioned in this thread are very useful. The concepts apply to other distributed version-control systems also.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum