Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » GIT
Re: GIT essentials [message #24377 is a reply to message #24373] Wed, 13 January 2010 09:47 Go to previous messageGo to next message
kohait00 is currently offline  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 Go to previous messageGo to next message
kohait00 is currently offline  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 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 680
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 #24396 is a reply to message #24387] Thu, 14 January 2010 01:52 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
kohait00 wrote on Wed, 13 January 2010 15:47

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.


If you're talking about http://gitorious.org/upp-mirror it wasn't updated since 6 December because when i've reinstalled the system i've lost my ssh key, now I have backup for it Smile and the repository will get updated every time I'm starting my laptop (that happen often). Also i've changed the user too, that's why is repo only 2 hours old. I think should be safe to use the repo from now on as I'm doing my graduation thesis with U++ and i'm using git for scm.

kohait00 wrote

takes around 4 hours to import the whole history.

I don't know what have you measured but it took me only half an hour to import whole history from upp-mirror Cool please don't scare new users Wink

Andrei
Re: GIT tryout [message #24400 is a reply to message #24396] Thu, 14 January 2010 12:19 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
thank you for your efforts,

well, i started at 8 am and was done at 11:40 am or something, might have been due to slow connection also, or mi laptop is kinda slow, a lot of maybes, but it was that long, nice to hear it can go faster.

Re: GIT tryout [message #24437 is a reply to message #24395] Sun, 17 January 2010 20:25 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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 #24442 is a reply to message #24437] Sun, 17 January 2010 23:37 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
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? Very Happy Just kidding.

Andrei
Re: GIT tryout [message #24447 is a reply to message #24442] Mon, 18 January 2010 01:21 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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? Very Happy Just kidding.

Andrei


Actually, I would try to reimplement monotone using U++. Database needs refactoring (text sha1 shouldn't be used within primary keys). Smile As a result of reimplementation size of a binary should shrink from 9M to 1.5M. Smile 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 tryout [message #24557 is a reply to message #24447] Sun, 24 January 2010 12:53 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
Just new links about git, and yes, you should read this Smile
http://hades.name/blog/2010/01/17/git-your-friend-not-foe/
http://hades.name/blog/2010/01/22/git-your-friend-not-foe-vo l-2-branches/
Re: GIT tryout [message #24578 is a reply to message #24557] Mon, 25 January 2010 05:32 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
andrei_natanael wrote on Sun, 24 January 2010 06:53

Just new links about git, and yes, you should read this Smile
http://hades.name/blog/2010/01/17/git-your-friend-not-foe/
http://hades.name/blog/2010/01/22/git-your-friend-not-foe-vo l-2-branches/


I like that:

"it is confusing ..."
"It will simply destroy the remote history ..."

And this is in an introduction for the beginners ...

Think several times before you start using this system. Smile


Regards,
Novo
Re: GIT tryout [message #24586 is a reply to message #24578] Mon, 25 January 2010 10:37 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
Novo wrote on Mon, 25 January 2010 06:32

andrei_natanael wrote on Sun, 24 January 2010 06:53

Just new links about git, and yes, you should read this Smile
http://hades.name/blog/2010/01/17/git-your-friend-not-foe/
http://hades.name/blog/2010/01/22/git-your-friend-not-foe-vo l-2-branches/


I like that:

"it is confusing ..."
"It will simply destroy the remote history ..."

And this is in an introduction for the beginners ...

Think several times before you start using this system. Smile


With a great power come a great responsibility. Right now the parts which i like at a DVCS are:

  • cloning speed
  • it's easy to create a branch and merge with another
  • new branch use the same place (i really like that because i'm not forced to create different assemblies in theide for different branches)


For me right now doesn't matter which DVCS but it have to have these features and probable more as i need them. I know that hg have better cross-platform implementation (because python) but i'm using git right now because it's supported better than others on some sites (gitorious, github) and there are many projects using it. I want a tool that doesn't stay in my way (frankly that happen with git sometimes).
Re: GIT [message #24587 is a reply to message #15990] Mon, 25 January 2010 10:45 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
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. Very Happy 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. Smile
Re: GIT [message #24629 is a reply to message #24587] Mon, 25 January 2010 23:19 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 680
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 Confused ).

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 Cool !!!

Re: GIT [message #24632 is a reply to message #24629] Tue, 26 January 2010 04:08 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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. Smile

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 Cool !!!



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. Smile

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. Smile


Regards,
Novo
Re: GIT [message #24647 is a reply to message #24632] Tue, 26 January 2010 11:33 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
Novo wrote on Tue, 26 January 2010 05:08


1) Check out a branch1:

mtn --db=database --branch=branch1 co .

2) Update to a branch branch2:

mtn --revision=h:branch2 update


That's something I personally dislike at monotone, it's showing you his internals. Using it you know you're using a VCS which use a database.
Another problem i have it's about generating RSA. mtn force you to have RSA key even if you're using it's repository locally. I really don't want a RSA key for my private repository, because i'm not sowing it to anyone over the network. I think it should be optionally.
If you'll follow monotone tutorial from http://www.monotone.ca/monotone.html you'll see how simple is to deal with it as a VCS Mad
I'm dreaming at the day when we will make usable software, the day when help manuals will disappear. Btw, i think bugs get into source becaus we don't know what we're doing and we don't know what other was doing.
Re: GIT [message #24702 is a reply to message #24647] Wed, 27 January 2010 20:12 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
andrei_natanael wrote on Tue, 26 January 2010 05:33

Novo wrote on Tue, 26 January 2010 05:08


1) Check out a branch1:

mtn --db=database --branch=branch1 co .

2) Update to a branch branch2:

mtn --revision=h:branch2 update


That's something I personally dislike at monotone, it's showing you his internals. Using it you know you're using a VCS which use a database.



You need to specify a database only once when you create a workspace. This nice feature lets you create multiple workspaces using only one repository/database. Smile

I personally find monotone much easier to use comparing to GIT and Mercurial. Though I miss good implementation of sub-modules.


Regards,
Novo
Re: GIT essentials [message #25289 is a reply to message #24373] Tue, 16 February 2010 14:35 Go to previous messageGo to next message
kohait00 is currently offline  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 #25290 is a reply to message #25289] Tue, 16 February 2010 14:42 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
could anyone explain why Uvs2 was bad? And what features it was lacking comparing to git and/or other version c. systems?
Re: GIT essentials [message #25292 is a reply to message #25290] Tue, 16 February 2010 15:45 Go to previous messageGo to next message
andrei_natanael is currently offline  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 ( Very Happy 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 Wink

Andrei
Re: GIT essentials [message #25295 is a reply to message #25292] Tue, 16 February 2010 16:52 Go to previous messageGo to previous message
fudadmin is currently offline  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 ( Very Happy 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??? Shocked

[Updated on: Tue, 16 February 2010 16:53]

Report message to a moderator

Previous Topic: Very nice icon set collection
Next Topic: Running Linux in a browser
Goto Forum:
  


Current Time: Fri Mar 29 01:02:17 CET 2024

Total time taken to generate the page: 0.02200 seconds