Home » Community » Coffee corner » GIT
| GIT [message #15990] |
Wed, 21 May 2008 22:22  |
|
|
|
I found GIT to be very fast. Importing 1500 files of uppsrc to git repo took only few seconds (on win32, p4 3ghz and msysgit). And Git dosn't create .git directory in every subdirectory. The only con right now is git needs to be installed on remote machine if we want our repo to be shared with others (bazaar dosn't have this restriction). I think we should move from uvs/svn to git. It's much more powerful. For example I can commit to my local repo not working code and sync it with remote repo if my changes will be finished. I have started to work on UltimateGit app (as there is no really good gui for git IMO) but I think we should finally add to TheIDE some kind of VCS interface so anyone willing could write plugin to his favourite VCS.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: GIT [message #16008 is a reply to message #16007] |
Thu, 22 May 2008 16:15  |
mdelfede
Messages: 1310
Registered: September 2007
|
Ultimate Contributor |
|
|
I don't think GIT is bad, I only think that it can bring troubles if people don't share often enough their local repositories....
Linus Thorvalds uses it for Linux Kernel, but that's an obvious choice because he wants to have the full control of repository and decide which patches to apply. Let's say that he uses it like a central repo, and people who wants their patches applied must share with him.
With svn, if you make a patch, you put on central repo and all people CAN fetch it when they wants. With git, you must update your repo, remember to share with all other people (OR setup some sort of central repository, but then, what's the advantage of a distributed one???) an other people must fetch AND sync their local copy. There's no more an "official" copy on which people works, if you don't setup a central public repository.
I see git much more useful to keep some sort of local history of your working copy.
BTW, the fact that svn puts "hidden" .svn folders everywhere (which are usually not hidden on windows...) disturbs me too, but it has the advantage to keep all stuff in a singkle tree.
I don't know how git works, but I gess that it must keep management data somewhere too.
Ciao
Max
|
|
|
|
| Re: GIT [message #16009 is a reply to message #16007] |
Thu, 22 May 2008 16:20 |
Novo
Messages: 1431
Registered: December 2006
|
Ultimate Contributor |
|
|
I’m using monotone at home. It is not that fast as GIT, but it has other advantages like one-file executable and one-file repository, which is an SQLITE database. I’ve been working a lot with CVS, SVN, and ClearCase. GIT seems to be closer to ClearCase. At least it has a familiar “rebase” command. In monotone everything is unfamiliar. I stuck once trying to merge different combinations of brunches, databases, and working copies. I’d recommend trying out similar merge operations with GIT. And “repair database” command in GIT scares me a little bit ...
Regards,
Novo
|
|
|
|
| Re: GIT [message #16335 is a reply to message #16009] |
Mon, 09 June 2008 09:03 |
|
|
I thing that it is a good link for comparation GIT and SVN. For my view I'd like GIT!
http://git.or.cz/gitwiki/GitSvnComparsion
| Quote: |
For example the Mozilla repository is reported to be almost 12 GiB when stored in SVN using the fsfs backend. The fsfs backend also requires over 240,000 files in one directory to record all 240,000 commits made over the 10 year project history. The exact same history is stored in Git by only two files totaling just over 420 MiB. SVN requires 30x the disk space to store the same history.
|
[Updated on: Mon, 09 June 2008 09:05] Report message to a moderator |
|
|
|
|
|
| Re: GIT [message #16351 is a reply to message #16342] |
Mon, 09 June 2008 21:19 |
|
|
| luzr wrote on Mon, 09 June 2008 07:28 |
Our infrastructure server will have no less than 300GB free (probably much more).
Mirek
|
Much more important to me than space is speed of git. Listing all files from repository, commits, updates are noticable faster than in svn. Opening upp project in SmartSvn takes a while (my UltimateGit does the same in few seconds. We should really consider git or bazaar in the near future.
|
|
|
|
|
|
|
|
| Re: GIT [message #16355 is a reply to message #16353] |
Mon, 09 June 2008 22:11 |
|
|
| luzr wrote on Mon, 09 June 2008 15:34 |
Will you make UltimateGit uvs2-like? 
(I mean single sync for multiple repositories?)
Mirek
|
Each repository has assigned a tab, so you can open many repos at once. Grouped operations are on to-do list
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: GIT [message #23068 is a reply to message #23067] |
Sun, 13 September 2009 23:31 |
Didier
Messages: 740
Registered: November 2008
Location: France
|
Contributor |
|
|
| Quote: |
I don't think that hg is the choice for everyone. Seems to me that big projects are using git. Gnome is using it, Qt too and also KDE is thinking to switch to it (amarok made the move). See the list from git site for almost every project using git.
I wish U++ to use git too
|
Open Solaris, Open JDK, Mozilla, Python, Xen, ... I think are big enough projects. 
Anyway it seems that GIT has done some progress on documentation since the last time I looked at it.
GIT and mercurial have exactly the same syntax for the main commands, but GIT seems more complicated for the other ones: that is what is usually said about GIT: complicated commands (at least what I read last year).
Anyway the point is to figure out what peaple will, and wan't to use. It seems many upp users work with windows so good windows integration is requested (I haven't tested the GIT Windows GUI).
Documentation is a central point: Mercurial has a complete, and yet simple documentation as well as many interesting plugins.
Simplicity of use is also a primary point: it seems that GIT and HG are just as easy to use (at least for the main commands)
I'm not saying GIT is better or worst than HG, I'm only saying it's worth looking closely at it before deciding to use GIT.
|
|
|
|
| Re: GIT [message #23071 is a reply to message #23067] |
Mon, 14 September 2009 10:45 |
andrei_natanael
Messages: 262
Registered: January 2009
|
Experienced Member |
|
|
| cocob wrote on Sun, 13 September 2009 23:10 |
is u++ used for big projects ??? no but it is a great tool ! This is not a argument.
cocob
|
Well, don't get me wrong. I have nothing against mercurial, i really like it because it's written in C/C++ and Python and it's not written in a mixture of languages like git(C, shell script, perls, tcl, python, etc.). It have the same features as git and and proves to be better supported on different platforms.
| Didier wrote |
Anyway the point is to figure out what peaple will, and wan't to use. It seems many upp users work with windows so good windows integration is requested
|
Both scm have svn integration so it's possible now to use both in development of U++, the only missing part is theIDE integration(using hg and git from theIDE).
I really like to see U++ going distributed using hg or git. Right now hg is better supported on Windows than git so it's by far the right choice to use it if Mirek think ever to move to a distributed scm.
The only thing remaining is the git popularity vs hg. Do we care about that?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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: 1431
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 521 times)
|
|
|
|
|
|
| Re: GIT essentials [message #24371 is a reply to message #24364] |
Wed, 13 January 2010 05:36 |
Novo
Messages: 1431
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: 1431
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 |
|
|
|
Goto Forum:
Current Time: Tue Apr 28 01:39:39 GMT+2 2026
Total time taken to generate the page: 0.01611 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
.)
