Home » Community » Coffee corner » GIT
|
|
|
|
|
|
|
|
|
|
| GIT essentials [message #24333 is a reply to message #23330] |
Mon, 11 January 2010 12:00   |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hi people,
i have been using svn in my company now for some time and it was ok, sometiimes it was a pain. and one time we even had a crash on the server, boom, the repo was gone, the history too. my fault, though. should have done backup before. well, life continued with the revision that was on my work laptop. with git, that cant happen.
the trunk/branches/tags model in svn (which is not obligatory though, but used widely) is kinda strict in a sense. it does not motivate a developper much to try and experiment with the codebase, because one fears the whole commit/revert/reread and filter the changes stuff.. and you always need the repo connection for looking up the history, the graph etc.. with git that is far esier.
admittable, git has a hard learning curve in the beginning, since the concepts are remarkably different from svn, so svn users espacially have their what?s and how?s at the beginning. but one could simply present them some tutorials and explain the basic things, so they get the picture.
the fact that everyone has its own repository, and mirek would need to pull is both an advantage and a disadvantage. he would not need to care much about commit right of other users, because *HE* needs to decide from whom to pull or not, this is all. he does not need to give anyone the commit right to its own git repo at all, basicly. so user management is franly different. mirek could be able try out some ideas and reject them without comment or polluting its own repo master branch. having a bunch of remote branches from *trusted* co contributers would make it easy to keep track. but probably this would make more work for him (more decision work especially), whereas now, he grants commit right to some users, trusting them not to pollute the trunk and does not need to take care of it anymore (but this is also possible in git). but if we consider that linus has as little time as mirek  and manages to handle kernel development with git (it actually was developped for that purpose), then it should be even easier.
i'd personally prefer to switch from svn to git, it is way superior to svn and many other scms (as far as i understood) and it should even be prefered over mercurial and other commercial projects, cause git will have a much wider accaptance and be wider used in future due to its open source nature. one can even say its more *standard* now. (look at all the major projects one by one dropping svn and heading for git).
we clearly have to destinct 2 things concerning usage of git for u++:
1) usage of git as scm for the Ultimate++ project *itself*
2) providing a git interface (among others, just like svn) in TheIDE to sync the user's project codebase when he uses git for it (has nothing to do with the ultimate++ project itself at all)
i think that was not clear cut apart in the preceeding posts
beeing using svn for quite some time, i started to switching to git, and still learning, have strived some of the tutrials and infos on the net over git. and so far, became more and more fixed in my decision to stay with git.
hope U++ will consider to move to git too. sorry for the long post
PS: Linus, the godfather of GIT making a really enjoyable talk about GIT itself, at google talk, focusing and adressing most of the topics we descuss here. is worth watching, makes some harsh jokes . this video made me think about switching. is quite long, but woth it.
http://www.youtube.com/watch?v=4XpnKHJAok8
|
|
|
|
|
|
|
|
|
|
|
|
| Re: GIT essentials [message #24345 is a reply to message #24343] |
Mon, 11 January 2010 17:19 |
mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
Well, the problem is that cloning(branching) with GIT is cheap, while with SVN it will take those 5+min. That's not good.
Then again as almost all U++ devs have limited access to SVN, and only very few people change the core of it (most of them used to old non-SVN way of syncing), they rarely run into conflicts or need of branches. Rest of us work mostly in Bazaar, which are reasonably small projects to rarely need a branch during development, and even then we would more likely create package_2 in bazaar in the very same trunk, mimicking branch behavior.
So I don't think right now there's huge benefit from using GIT.
If Mirek and other core developers have some spare time, it would probably make sense to try it out. If U++ core contributors will grow more in the future, the benefit from switch may be even greater. But right now I personally don't see this as big priority (then again I'm not core dev and rarely contributing even into bazaar, so who cares what I think ).
Also I think if you are proposing this, you should maybe try also design the work-flow model, i.e. how Mirek will remain the master of U++, yet other contributors will submit patches with GIT to him. So once he will want to try it out, he can read some ideas how it should work in U++ community. (because GIT allows many ways of cooperation)
What's puzzling *me* as non-user of git is the "pull". I understand anyone can clone repo, do his changes, prepare public commit (patch) and tell maintainer of project it's really great improvement and he should adopt it. Then comes the "pull" by maintainer from the contributor's repo? So everyone's personal repository has to be on public IP? (I find this unlikely with current U++ contributors)
I know this can be worked around by submitting patches for example trough e-mail, or by letting contributor to instead push into central repo, I'm just asking if I understand this part correctly. I think for really democratic/decentralized development (I'm NOT saying the U++ needs this, I think current way works quite ok right now, maybe in future we will need change, but not yet?) everyone should have his own repo and basically Mirek as site owner will use very likely his own repo to create official distribution, so if he does like something from somebody else, he will pull it and add to official U++. I wonder how well that works in current age of IPv4 and NATs. Maybe I misunderstood something important about DVCS/GIT?
|
|
|
|
| Re: GIT essentials [message #24347 is a reply to message #24345] |
Mon, 11 January 2010 17:59 |
andrei_natanael
Messages: 262
Registered: January 2009
|
Experienced Member |
|
|
| mr_ped wrote |
Well, the problem is that cloning(branching) with GIT is cheap, while with SVN it will take those 5+min. That's not good.
|
Actually branching in git takes almost not time.
real 0m0.044s
user 0m0.000s
sys 0m0.010s
Cloning the main repository takes 1 minute and equivalent of clone is checkout in svn I guess(in git checkout is a different operation).
| mr_ped wrote |
Also I think if you are proposing this, you should maybe try also design the work-flow model, i.e. how Mirek will remain the master of U++, yet other contributors will submit patches with GIT to him. So once he will want to try it out, he can read some ideas how it should work in U++ community. (because GIT allows many ways of cooperation)
|
Mirek will remain the master of U++. We may follow Linus work-flow, Mirek as dictator and perhaps if U++ will grow more other persons as lieutenants. Right now Mirek being single person who will decide what goes in repo is the right choice.
| mr_ped wrote |
What's puzzling *me* as non-user of git is the "pull". I understand anyone can clone repo, do his changes, prepare public commit (patch) and tell maintainer of project it's really great improvement and he should adopt it. Then comes the "pull" by maintainer from the contributor's repo? So everyone's personal repository has to be on public IP? (I find this unlikely with current U++ contributors)
I know this can be worked around by submitting patches for example trough e-mail, or by letting contributor to instead push into central repo, I'm just asking if I understand this part correctly. [...] Maybe I misunderstood something important about DVCS/GIT?
|
You shouldn't have a public IP, for that exists sites like gitorious, googlecode, sourceforge. If someone wants to let Mirek see his changes he will push changes to his own repo from one of those sites and send to Mirek a link to it.
Perhaps if we take a realistic situation it will be more easier to understand that. I have a clone of U++ at gitorious, and also a local clone of if. If i will make changes to local clone and merge changes with the master branch from gitorious my repo will diverge from current U++ repo (supposing it's using git). Now i may send to Mirek a link to my repo, he will clone it (or only clone last revision) and if he like it he will merge mine repo with U++ main repo. I don't have to tell to anyone my IP (my IP is dynamic anyway and telling one will have no effect next time because it may get changed). No need to use a central repo, no emailed patches.
I don't understand yet very well git but as i understand now it makes more sense to me to use it than using svn. If I'll make changes to Chameleon with git i have to do simple operations:
git branch cham-changes
git checkout cham-changes
// change the code
git commit -a
git checkout master
// if i'm glad with changes
git merge cham-changes
git commit -a
git branch -d cham-changes
// if i'm not pleased with changes
git branch -D cham-changes
With svn i'll have to change the files... if i dislike the changes... revert them... in the meantime i cannot work on something else because the repo is blocked by my changes to Chameleon. To solve this i have to use branches in svn too, it take time and i don't know how hard is to merge them... perhaps someone with merging experience will tell me. In git merging is so simple .
|
|
|
|
| Re: GIT essentials [message #24352 is a reply to message #24347] |
Tue, 12 January 2010 06:07 |
Novo
Messages: 1433
Registered: December 2006
|
Ultimate Contributor |
|
|
Just my two cents.
A couple years ago I had the same problem: my CVS server broke down and I lost one year history. Fortunately, I had backups from previous years.
After a short research I chose "monotone".
Cons:
1) It is just one executable (plus a couple of dlls). You don't really need to install it.
2) It is quite powerful. Actually, GIT borrowed a lot of ideas from monothone.
3) It is easy to use. Monotone has not that big set of commands.
4) Repository and workspace can be located in different places. (You can have different workplaces for the same branch. Actually, I'm using this for a different purpose.)
Pros:
1) No usable GUI. Nothing similar to TortoiseSVN or TortoiseGIT.
2) Not very popular. Actually, the same can be told about U++. Though, that doesn't make it bad.
The only thing I'm missing about monotone is GUI, which can be easily developed using U++, because monotone stores repository in SQLITE database.
A week ago I tried to migrate from monotone to GIT because of lack of GUI. That didn't happen because I couldn't resolve several work-flow issues.
1) GIT keeps repository and workspace in the same directory. In order to checkout another branch you need to clone repository. Basically, this means that you cannot store several projects in one repository. This is not a problem with monotone. In my case "branch" is often equal to "project".
2) U++ is a set of "packages". When I create a new project I want to assemble it from several "packages". This is possible with GIT, but in this case each package should be represented as a separate GIT repository. This seems to be way too complicated.
I'd like to get more feedback about work-flows with distributed VCS from you guys.
TIA
Regards,
Novo
|
|
|
|
|
|
| Re: GIT essentials [message #24359 is a reply to message #24352] |
Tue, 12 January 2010 10:58 |
andrei_natanael
Messages: 262
Registered: January 2009
|
Experienced Member |
|
|
| Novo wrote on Tue, 12 January 2010 07:07 |
After a short research I chose "monotone".
Pros:
1) It is just one executable (plus a couple of dlls). You don't really need to install it.
2) It is quite powerful. Actually, GIT borrowed a lot of ideas from monothone.
3) It is easy to use. Monotone has not that big set of commands.
4) Repository and workspace can be located in different places. (You can have different workplaces for the same branch. Actually, I'm using this for a different purpose.)
|
I like your writing mistake about pros and cons, IMO your pros are cons  .
1) How extensible is it? If we want to create a hook for some operation or replace one part with our i.e. diff?
2) ... (the counterparts are too) ...
3) Easy to use not always means less commands, monotone stay in my way because it's doing simple things complicated. I've tried once to help pidgin development and implement some features which i needed but I've hit monotone wall and I quited. A scm should not stay in your way, it should be expressive enough not to impose limits but not too expressive to let you doing same thing in thousand different ways.
4) IMO it just complicate my life 
| Novo wrote |
The only thing I'm missing about monotone is GUI, which can be easily developed using U++, because monotone stores repository in SQLITE database.
|
While others want a GUI on top of scm tool I want it to be integrated with my tools. I.e. I create project in theIDE (or other ide), i'm adding new source files, do some codding, then i initialize a repository (from theIDE) and do initial commit. Supposing that i have a working program and want to test new stuff. I'm creating a branch (from theIDE AnySCM->NewBranch), theIDE reloads all opened files and these contain data from new branch, note that i've not changed project location, so the branch reside in same directory and i may switch to other branch if i want and that's cool because i don't have to create a different package in theIDE just to try new things (i'm reusing the same interface, just switching from one branch to another). I'm doing some modification to this branch, i'm testing changes and if it's ok i'm merging it in master branch (AnySCM->Merge<branch-name>).
IMO that's a nice way to get stuff done.
| Novo wrote |
1) GIT keeps repository and workspace in the same directory. In order to checkout another branch you need to clone repository. Basically, this means that you cannot store several projects in one repository. This is not a problem with monotone. In my case "branch" is often equal to "project".
2) U++ is a set of "packages". When I create a new project I want to assemble it from several "packages". This is possible with GIT, but in this case each package should be represented as a separate GIT repository. This seems to be way too complicated.
I'd like to get more feedback about work-flows with distributed VCS from you guys.
|
1) I think you don't have to clone the repo to checkout another branch. You do the checkout and reuse the same space and if you want to switch to master branch just checkout it.
~$ git branch
master *
your-cool-branch
~$ git checkout your-cool-branch
# now where your project is, you have your-cool-branch source code in place
# working...
~$ git commit -a
~$ git checkout master
# yay, we are on master branch on the same location
# and i think that's cool
2) Not every package should be a separate repository, i would make assembly(nest?) a repository, perhaps only for MyApps i wouldn't do that because packages from it may not be related one to other.
Just my 2 cents.
I think we should consider others dvcs for scm but IMO the leading scm which will be used for a long time from now will be git, hg and bzr.
Git - surfer from code fragmentation(shell code, perl, python, C, tcl, etc.), making it a bit unportable.
Bzr - a bit slow, it's written in python but cross-platform is achieved.
Hg - i don't have an opinion, i've used it only once (tried the tutorial) so no real life experience with it.
|
|
|
|
| Re: GIT essentials [message #24360 is a reply to message #24355] |
Tue, 12 January 2010 11:36 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
the basic question is indeed, as somone above mentioned: does it matter to migrate *right now*? the workflow seems to be alright for now, but could significantly change in future.
it s really the question of workflow models, so far nobody can imagine a truely practicable solution. maybe it's due to the fact that git *is* different from svn, it stores repo/history locally and completely (if you clone, or partially if you pull). as far as everyone can pull from anyother, there is a different user handling model.
now, as far as i understand, there is almost the dictator/leutnant model, using svn. mirek beeing master commiter, having some trusties, who also have commit rights, but use them with care (paying head and pants to mirek if things go wrong ), so this is bit of security issue. people contributing and lacking commit rights do this by supplying test projects in forum, or like me most times, just some lines in plain text with the file:line pattern so mirek needs to sit down, search the file, *think*, change the line and commit. he is actually a busy master/dictator.
with git this could go just as before, but somehow ease it for mirek. he could have his own git repo, the "MAIN" repo, creating releases from, often times refered as the "blessed repository", publically readable, but commit rights only for mirek.
his leutnants, just as the rest of the world, keep synced with the blesses repo, always pulling from it (as the origin repo, in git terms).
the leutnants are just helpers in u++ case, and either have an own and somehow accessable repo for mirek, where *he* can pull from in his branches, and then he can merge. or it would be easier for now, if they also had comit rights to the blessed repo as well, so this would be just the same situation as before with svn.
he would mainly benefit from the easyness of branch merging with git.
when we expect u++ users to supply patches, just as in kernel issues, this would be too much. they are not that experienced, and neither that engaged with u++ . so even the workflow with forum bugfix posting and contributions would go on for quite a while just the same, as long as we dont provide some better means for contributions, i.e. a howto setup own public git repo, where a engaged contributer can commit his changes and mirek pull from.
so its mainly a ideologic dessision for now, it *would* have some benefits, but they are not that extraweighted as to justify a migration to git. i personally would still prefer git, for even more but presently for u++ unimportant reasons. maybe just one still to mention: it seems not to be that much fixed in structure, is really flexible, where every developper is responsable for itself. this is not the case with svn, where 'anyone' can pollute the repo.
attached is a one popular model of how things are drive, bold arrows is commit, other is pull. all are repos, either private on working machine or public on github or gitorious.
if we really want mirekt to be convinced, we need to more clearly elaborate a better workflow model, though. so far, he'd understandably not see the need to migrate.
-
Attachment: gitmodel.JPG
(Size: 33.29KB, Downloaded 1120 times)
|
|
|
|
|
|
| Re: GIT essentials [message #24371 is a reply to message #24364] |
Wed, 13 January 2010 05:36 |
Novo
Messages: 1433
Registered: December 2006
|
Ultimate Contributor |
|
|
| Didier wrote on Tue, 12 January 2010 15:28 |
Currently I use an HG repository for the UPP code.
I update it directly from the UPP SVN
repository by using the hgpullsvn utility.
The pending hgpushsvn utility also exists.
So I use HG locally while the repo is still under SVN.
This approach could be a good test before deciding SCM A or B
|
I completely agree with this. GIT can be easily synchronized with SVN. If your favorite DVCS doesn't have native synchronization support, then you can use Tailor (http://progetti.arstecnica.it/tailor).
Regards,
Novo
|
|
|
|
|
|
| Re: GIT essentials [message #24373 is a reply to message #24359] |
Wed, 13 January 2010 06:40 |
Novo
Messages: 1433
Registered: December 2006
|
Ultimate Contributor |
|
|
| 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".
Pros:
1) It is just one executable (plus a couple of dlls). You don't really need to install it.
2) It is quite powerful. Actually, GIT borrowed a lot of ideas from monothone.
3) It is easy to use. Monotone has not that big set of commands.
4) Repository and workspace can be located in different places. (You can have different workplaces for the same branch. Actually, I'm using this for a different purpose.)
|
I like your writing mistake about pros and cons, IMO your pros are cons .
1) How extensible is it? If we want to create a hook for some operation or replace one part with our i.e. diff?
2) ... (the counterparts are too) ...
3) Easy to use not always means less commands, monotone stay in my way because it's doing simple things complicated. I've tried once to help pidgin development and implement some features which i needed but I've hit monotone wall and I quited. A scm should not stay in your way, it should be expressive enough not to impose limits but not too expressive to let you doing same thing in thousand different ways.
4) IMO it just complicate my life
|
1) Monotone uses Lua for scripting. It allows you to create hooks. Though, I haven't tried to do that myself.
2) I just wanted to say that they are similar.
3) Could you, please, describe the problem in more details? I'm trying to learn different workflows.
4) You need to synchronize your repository only once in this case. May be I'm wrong, but if my project is build from a dozen of independent submodules, and I want to update the code, then I need to update all these repositories manually (or to develop a script).
| Quote: |
| Novo wrote |
The only thing I'm missing about monotone is GUI, which can be easily developed using U++, because monotone stores repository in SQLITE database.
|
While others want a GUI on top of scm tool I want it to be integrated with my tools. I.e. I create project in theIDE (or other ide), i'm adding new source files, do some codding, then i initialize a repository (from theIDE) and do initial commit. Supposing that i have a working program and want to test new stuff. I'm creating a branch (from theIDE AnySCM->NewBranch), theIDE reloads all opened files and these contain data from new branch, note that i've not changed project location, so the branch reside in same directory and i may switch to other branch if i want and that's cool because i don't have to create a different package in theIDE just to try new things (i'm reusing the same interface, just switching from one branch to another). I'm doing some modification to this branch, i'm testing changes and if it's ok i'm merging it in master branch (AnySCM->Merge<branch-name>).
IMO that's a nice way to get stuff done.
|
IMHO all VCS can be integrated with TheIDE. IMHO all DVCS let you use the same directory to checkout different branches. Not all DVCS let you checkout into multiple places. And DVCS's do not let you do partial checkout. You get all or nothing.
I personally need GUI to be able to browse big logs, and to be able easily compare different versions of a file. It is hard for me to type long SHA1 keys. I'm not using mouse.
| Quote: |
| Novo wrote |
1) GIT keeps repository and workspace in the same directory. In order to checkout another branch you need to clone repository. Basically, this means that you cannot store several projects in one repository. This is not a problem with monotone. In my case "branch" is often equal to "project".
2) U++ is a set of "packages". When I create a new project I want to assemble it from several "packages". This is possible with GIT, but in this case each package should be represented as a separate GIT repository. This seems to be way too complicated.
I'd like to get more feedback about work-flows with distributed VCS from you guys.
|
1) I think you don't have to clone the repo to checkout another branch. You do the checkout and reuse the same space and if you want to switch to master branch just checkout it.
~$ git branch
master *
your-cool-branch
~$ git checkout your-cool-branch
# now where your project is, you have your-cool-branch source code in place
# working...
~$ git commit -a
~$ git checkout master
# yay, we are on master branch on the same location
# and i think that's cool
2) Not every package should be a separate repository, i would make assembly(nest?) a repository, perhaps only for MyApps i wouldn't do that because packages from it may not be related one to other.
Just my 2 cents.
|
1) Yes, GIT is designed to use only one directory and work with only one project. It is a fixed workflow. Actually, the way you use GIT in your example is not exactly a GIT way. You completely bypass Index. Index is a nice feature to get rid of temporary branches.
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.
Probably, I want too much.
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.
Regards,
Novo
[Updated on: Wed, 13 January 2010 06:52] Report message to a moderator |
|
|
|
| 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: 740
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: 1433
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: 1433
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: 740
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: 1433
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: 1324
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: Sun Oct 04 22:47:16 GMT+2 2026
Total time taken to generate the page: 0.33319 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
