View previous topic :: View next topic |
Author |
Message |
eyoung100 Veteran
Joined: 23 Jan 2004 Posts: 1428
|
Posted: Tue Nov 12, 2013 10:53 pm Post subject: |
|
|
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 |
|
|
1clue Advocate
Joined: 05 Feb 2006 Posts: 2569
|
Posted: Tue Nov 12, 2013 11:12 pm Post subject: |
|
|
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 |
|
|
1clue Advocate
Joined: 05 Feb 2006 Posts: 2569
|
Posted: Tue Nov 12, 2013 11:18 pm Post subject: |
|
|
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 |
|
|
eyoung100 Veteran
Joined: 23 Jan 2004 Posts: 1428
|
Posted: Tue Nov 12, 2013 11:24 pm Post subject: |
|
|
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 |
|
|
1clue Advocate
Joined: 05 Feb 2006 Posts: 2569
|
Posted: Tue Nov 12, 2013 11:55 pm Post subject: |
|
|
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 |
|
|
wjb l33t
Joined: 10 Jul 2005 Posts: 605 Location: Fife, Scotland
|
Posted: Wed Nov 13, 2013 1:07 am Post subject: |
|
|
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 |
|
|
666threesixes666 Veteran
Joined: 31 May 2011 Posts: 1248 Location: 42.68n 85.41w
|
|
Back to top |
|
|
1clue Advocate
Joined: 05 Feb 2006 Posts: 2569
|
Posted: Wed Nov 13, 2013 1:49 am Post subject: |
|
|
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:
- Linus started with tarballs and patches for revision control.
- He hates CVS and SVN, has never used them for the kernel but did use CVS while working for a company.
- He went to BitKeeper for awhile, and this is what convinced him that a SCM was worth using.
- He used three criteria to find a satisfactory SCM, and that basically eliminated everything available. See later.
- He wrote git in two weeks, and it was better than anything else available.
Three criteria:
- Must be distributed.
- Must be fast.
- 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 |
|
|
Yamakuzure Advocate
Joined: 21 Jun 2006 Posts: 2284 Location: Adendorf, Germany
|
Posted: Wed Nov 13, 2013 4:05 pm Post subject: Re: Version control system recommendation? |
|
|
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. _________________ Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
Back to top |
|
|
schorsch_76 Guru
Joined: 19 Jun 2012 Posts: 450
|
Posted: Wed Nov 13, 2013 5:52 pm Post subject: |
|
|
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.
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:
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 |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1655
|
Posted: Wed Nov 13, 2013 9:50 pm Post subject: |
|
|
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 |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1655
|
Posted: Wed Nov 13, 2013 10:11 pm Post subject: |
|
|
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 |
|
|
eyoung100 Veteran
Joined: 23 Jan 2004 Posts: 1428
|
Posted: Wed Nov 13, 2013 11:09 pm Post subject: |
|
|
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 _________________ 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 |
|
|
schorsch_76 Guru
Joined: 19 Jun 2012 Posts: 450
|
Posted: Thu Nov 14, 2013 6:27 am Post subject: |
|
|
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 |
|
|
Maitreya Guru
Joined: 11 Jan 2006 Posts: 441
|
Posted: Thu Nov 14, 2013 11:05 am Post subject: |
|
|
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 |
|
|
1clue Advocate
Joined: 05 Feb 2006 Posts: 2569
|
Posted: Thu Nov 14, 2013 8:42 pm Post subject: |
|
|
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 |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1655
|
Posted: Fri Nov 15, 2013 1:18 am Post subject: |
|
|
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 |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 488 Location: Gainesville, FL, USA
|
Posted: Fri Nov 15, 2013 8:00 am Post subject: |
|
|
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 |
|
|
|
|
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
|
|