|
|
|
Home » Community » Coffee corner » GIT
| Re: GIT essentials [message #24377 is a reply to message #24373] |
Wed, 13 January 2010 09:47   |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
concerning the GUI parts of git (with usability in mind when thinking of switching u++ project repo to git):
The Git GUI is quite usefull, supporting most of the command line features. a nice history few (one needs to get familiar with the view though, its due to different model than svn graph)
furthermore, there is TortoiseGIT for windows, which is in appearance relative to TortoiseSVN. it seems quite same in usage, though i havent tried it extensively.
concerning integration of git in TheIDE, just like SlikSVN, one can use the well defined command line operations in cygwin environment, though this is not trivial, i think.
|
|
|
|
| GIT tryout [message #24387 is a reply to message #24373] |
Wed, 13 January 2010 14:47 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
for all who want to play around with git and u++:
in a post above, there was a link, but is not quite current anymore.
download and install git for windows i.e.
http://msysgit.googlecode.com/files/Git-1.6.5.1-preview20091 022.exe
when installing, choose with the radio buttons, to modify your PATH, should make no problems. and choose to commit lineendings as is.
then from git bash:
mkdir uppgit
cd uppgit
git svn clone -s http://upp-mirror.googlecode.com/svn .
takes around 4 hours to import the whole history.
total size 260 MB.
first time starting the GitGUI and opening the repo sinals 7000 loose objects, just allow to compress, and its gone, leaving you with a nice, clean clone of uppsvn.
normally, one can run
git svn fetch
or something like that, to keep in touch with svn repo, and
git svn rebase
to apply the changes (dont sure)
from git help:
"...After a repository is cloned, the fetch command will be able to update revisions without affecting the working tree; and the rebase command will be able to update the working tree with the latest changes. ..."
enjoy
|
|
|
|
| Re: GIT tryout [message #24395 is a reply to message #24387] |
Wed, 13 January 2010 22:55 |
Didier
Messages: 725
Registered: November 2008
Location: France
|
Contributor |
|
|
Hi Novo,
| Quote: |
This all is about workflows.
I personally trying to figure out which DVCS i need to use (and how to use it) in case of complicated code structure, many projects, many external projects, many versions of same code, plus U++, plus e.t.c.
All your suggestions are welcome. I appreciate your feedback.
|
Well in HG there there are lot's of extensions
http://mercurial.selenic.com/wiki/UsingExtensions#Extensions _Bundled_with_Mercurial
And in particular the Forest extension which allows to manage sub repositories inside a global repo: maybe this sounds a bit like what you need.
This plugin is still in beta state but it's very promising and it would fit very well to the Upp package organisation Or at least in bazaar
[Updated on: Wed, 13 January 2010 23:04] Report message to a moderator |
|
|
|
|
|
|
|
| Re: GIT tryout [message #24437 is a reply to message #24395] |
Sun, 17 January 2010 20:25 |
Novo
Messages: 1430
Registered: December 2006
|
Ultimate Contributor |
|
|
| Didier wrote on Wed, 13 January 2010 16:55 |
Hi Novo,
| Quote: |
This all is about workflows.
I personally trying to figure out which DVCS i need to use (and how to use it) in case of complicated code structure, many projects, many external projects, many versions of same code, plus U++, plus e.t.c.
All your suggestions are welcome. I appreciate your feedback.
|
Well in HG there there are lot's of extensions
http://mercurial.selenic.com/wiki/UsingExtensions#Extensions _Bundled_with_Mercurial
And in particular the Forest extension which allows to manage sub repositories inside a global repo: maybe this sounds a bit like what you need.
This plugin is still in beta state but it's very promising and it would fit very well to the Upp package organisation Or at least in bazaar
|
Hi Didier,
Thanks for pointing out. It looks like Mercurial has a build in support for sub-projects since v 1.3.
I checked sub-project support in both Git and Mercurial. In both cases it seems to be somewhat confusing to me. There are many "don't do that" cases in both systems. Right now my preferences lean to Mercurial. I'll keep experimenting.
Below are links for those, who is looking for a new distributed VCS.
A Guide to Branching in Mercurial (pretty cool analysis, comments are also cool) - http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me rcurial/
Git workflows:
http://osteele.com/archives/2008/05/my-git-workflow
http://osteele.com/archives/2008/05/commit-policies
Regards,
Novo
|
|
|
|
|
|
| Re: GIT tryout [message #24447 is a reply to message #24442] |
Mon, 18 January 2010 01:21 |
Novo
Messages: 1430
Registered: December 2006
|
Ultimate Contributor |
|
|
| andrei_natanael wrote on Sun, 17 January 2010 17:37 |
With all this movement around DVCS in U++ forum, i think we have to start making our own DVCS, named Sit (Simple Information Tracker or Stay In Touch [with the code, of course]), sure it may not be wide used but anyway it's made by us for us, anyone for reviving UVS?  Just kidding.
Andrei
|
Actually, I would try to reimplement monotone using U++. Database needs refactoring (text sha1 shouldn't be used within primary keys).  As a result of reimplementation size of a binary should shrink from 9M to 1.5M. Unfortunately, this task doesn't have highest priority for me. For the next half a year I'm going to stick to the old-fashioned monotone.
Regards,
Novo
|
|
|
|
|
|
|
|
|
|
| Re: GIT [message #24587 is a reply to message #15990] |
Mon, 25 January 2010 10:45 |
mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
I'm trying to get the grasp with GIT too, at least reading such articles, but I have difficult times as well.
I never hit any merge problems with SVN hard (thanks to my limited usage of it mostly, and little to my understanding how to do it in proper SVN way). My biggest problem with SVN is accidentally hitting commit with unfinished log message.
That said, the git does solve very little of my problems, as you can see. I think if I would join a more OSS project with more distributed decentralized development, I would hit limits of SVN much harder and welcome GIT.
And that's probably true for future of U++, I think in the long term (10+ years) it's inevitable to further loose the connection to mirek so the U++ would survive even without him later. If there will be still a point to have C++ framework at all. But right now I feel very confused by GIT. I can see easily how Linus would be unable to work with SVN, but for the scale of project I work on, SVN fits it almost perfectly. :/
Yes, I'm sort of ranting I did expect bigger magic from GIT. And at the same time admitting it's superior. Looks like I'm crazy or momentarily confused too much.
But keep these things coming, I think at this rate I will try to use GIT in next months, after all it never hurts to learn something new, although in my case it keeps pushing the older things out of my head, so I have to choose wisely what set of technologies I do support at the same time.
|
|
|
|
| Re: GIT [message #24629 is a reply to message #24587] |
Mon, 25 January 2010 23:19 |
Didier
Messages: 725
Registered: November 2008
Location: France
|
Contributor |
|
|
Hi,
I started using DVCS's more than 10 years ago with RIP TEAMWARE, the Solaris (I think ) version for DVCS wich doesn't exist any more (Their build environment is not maintained any more  ).
Since then I used Clearcase/CVS/SVN and now HG.
The main concept about DVCS that you need to catch is the cloning part:
When you clone a project you don't only get a copy, you get a LINKED copy with local history, with which you can exchange history data (push/pull) and make merges if you want.
You can also exchange changesets (==history data) with any other clone, through http for example, as long as it has the same base history.
==> this allows you to give or receive from another developer selected changesets/branch or complete history update WITHOUT disturbing the main repository.
==> this gives a handy way for a distributed team to share changes before they are actually pushed to the main repository.
And when the changes are finalised, all that has to be done is to push them up to the main repository and there will be no conflicts !
This is the other great part about DVCS, all the conflicts are solved locally.
Of course with enhancements like in HG and GIT you can do exactly the same with local branches. But even then, these branches can also be exchanged with other clones.
My experience shows me that this is the only way that allows an easy management of complex merges between many developers where history can get very complex.
Once you have tasted DVCS and really learned to use it at its full power, you cannot come back no matter which DVCS you are using  !!!
|
|
|
|
| Re: GIT [message #24632 is a reply to message #24629] |
Tue, 26 January 2010 04:08 |
Novo
Messages: 1430
Registered: December 2006
|
Ultimate Contributor |
|
|
| Didier wrote on Mon, 25 January 2010 17:19 |
Since then I used Clearcase/CVS/SVN and now HG.
|
In my case it is CVS/Clearcase/SVN/Perforce and now I'm using monotone at home.
| Quote: |
Once you have tasted DVCS and really learned to use it at its full power, you cannot come back no matter which DVCS you are using !!!
|
Imagine a project, which employs several hundreds developers, and VCS has several hundred thousands revisions. You will not be able to clone a repository in this case.
Actually, I figured out how to switch to a different branch in monotone.
1) Check out a branch1:
mtn --db=database --branch=branch1 co .
2) Update to a branch branch2:
mtn --revision=h:branch2 update
So, now I know how to work with different branches using only one directory with three different DVCS: GIT, Mercurial, and Monotone.
Regards,
Novo
|
|
|
|
|
|
|
|
| Re: GIT essentials [message #25289 is a reply to message #24373] |
Tue, 16 February 2010 14:35 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
[quote title=Novo wrote on Wed, 13 January 2010 06:40][quote title=andrei_natanael wrote on Tue, 12 January 2010 04:58]| Novo wrote on Tue, 12 January 2010 07:07 |
After a short research I chose "monotone".
2) I personally have ~30 packages in my MyApps. I do not want to checkout this mess all the time. I want to checkout a project and get only necessary packages. And when I update my project, I want these packages get updated. But in case when I use an external code, I do not want it to be updated all the time. I want to "rebase" it manually.
|
this is indeed a major issue with git. you cant say to one of your projects in your git repo "update to a certain revision", while leaving the rest of your packages beeing up to head revision i.e. thats because git is trating the entire base directory as content as mentionend by someone. you could check out earlier commits, but that would probably also change the state of the other packages, f they had been worked on meanwhile. in that case, svn is usefull actually..
i'm not that experienced in git to provide a workaround to this. probably the solution lies in an inteligent branching workflow. so one could checkout branch and rebase there some stuff needed from other packages or the like.
but since git is cheap, one could use a repo for each project as well. this is the apporach Xorg is doing, if you take a look inside the buildscript, the pull a bunch of repos, not just one.
i still believe, git is to be favored above others, since it's the most promising technology, not neccesarily because its the best, but because its a de facto standard in Open Source now and is pushed there. new promising technologies like u++ can profit A LOT, just by sticking to some stadard interfaces. the time of svn is running out.
|
|
|
|
|
|
| Re: GIT essentials [message #25292 is a reply to message #25290] |
Tue, 16 February 2010 15:45 |
andrei_natanael
Messages: 262
Registered: January 2009
|
Experienced Member |
|
|
| fudadmin wrote on Tue, 16 February 2010 15:42 |
could anyone explain why Uvs2 was bad? And what features it was lacking comparing to git and/or other version c. systems?
|
I've used it only few times but if i remember correctly reasons were:
- not a wide used tool so every developers wanting to commit to U++ had to learn it and it wasn't released together with U++ or TheIDE, so one had to build it from uppbox folder... IIRC initially it was existing only on private repository
- compared to git, uvs isn't a DVCS
- i don't know if branching and merging was possible
- looked like U++ developer suffer from Not Invented Here syndrome and abandoning Uvs and choosing an external tool for SCM spread any rumors ( no, it's not a reason, but we have our own IDE, our(STL) NTL, our own Image format [with hot-spots], site is made with U++ made tools)
Perhaps one should make a comparison between Uvs and SVN, GIT, BZR, etc. maybe we get back to it 
Andrei
|
|
|
|
| Re: GIT essentials [message #25295 is a reply to message #25292] |
Tue, 16 February 2010 16:52 |
 |
fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
|
Ultimate Contributor
Administrator |
|
|
| andrei_natanael wrote on Tue, 16 February 2010 14:45 |
| fudadmin wrote on Tue, 16 February 2010 15:42 |
could anyone explain why Uvs2 was bad? And what features it was lacking comparing to git and/or other version c. systems?
|
- looked like U++ developer suffer from Not Invented Here syndrome and abandoning Uvs and choosing an external tool for SCM spread any rumors ( no, it's not a reason, but we have our own IDE, our(STL) NTL, our own Image format [with hot-spots], site is made with U++ made tools)
Andrei
|
So, Linus can suffer from this sindrom, we not??? 
[Updated on: Tue, 16 February 2010 16:53] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Tue Apr 29 08:18:58 CEST 2025
Total time taken to generate the page: 0.01483 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
