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 [message #23073 is a reply to message #23071] Mon, 14 September 2009 16:36 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Hello all

I use Mercurial (hg) as user because it is used in Eigen math library.

It is so easy that I use it through the command line.

Best regards
Koldo


Best regards
IƱaki
Re: GIT [message #23074 is a reply to message #23067] Mon, 14 September 2009 22:10 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cocob wrote on Sun, 13 September 2009 16:10

is u++ used for big projects ???


Define "big"....

Mirek
Re: GIT [message #23076 is a reply to message #23074] Tue, 15 September 2009 14:01 Go to previous messageGo to next message
sapiency is currently offline  sapiency
Messages: 56
Registered: September 2008
Member
nevertheless,

but what about the idea to support git from theide?

reinhard
Re: GIT [message #23329 is a reply to message #23076] Sat, 10 October 2009 15:41 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
Hi,
I've created a upp mirror on gitorious.org so everyone who want to use git for upp development may clone the repo from there (I'll try to keep it in sync with upp svn mirror).
Why?
Doing programs sometimes require to modify some packages from upp and cannot push them to upstream, so it's simple to keep them in a separate branch and git make branch merge and creation more simple than svn. Also the cloning of git repository take few seconds compared to svn checkout which take minutes. If i want to create a program with some customized code based on upp upstream code is simple to create a branch and work on it.

Quote:

nevertheless,

but what about the idea to support git from theide?

reinhard


I would like to see that too Smile
Re: GIT [message #23330 is a reply to message #23329] Sat, 10 October 2009 15:45 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
I forget the link
http://gitorious.org/upp-mirror
GIT essentials [message #24333 is a reply to message #23330] Mon, 11 January 2010 12:00 Go to previous messageGo to next message
kohait00 is currently offline  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 Smile 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 Smile

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 Smile. this video made me think about switching. is quite long, but woth it.
http://www.youtube.com/watch?v=4XpnKHJAok8
Re: GIT essentials [message #24338 is a reply to message #24333] Mon, 11 January 2010 16:07 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
I would like too that U++ use git Smile

When I've made a full checkout last time I've measured checkout time for subversion and clone time for git. I've used my U++ git clone repo from gitorious (it's not updated since 6 December, 2009) and the result's are quite impressive.

svn
real 37m23.956s
user 0m49.850s
sys 0m29.460s


git
real 1m27.702s
user 0m10.170s
sys 0m2.400s

The clone of U++ repository take only 1 minute and half compared to more than half hour for svn.

It's simply when you work on something to create a new branch, work on that and if you have right results merge it to master else drop it. Branching is more easier than with svn. I didn't done a svn branch merging but I've heard that's pure pain.

Here comes another advantage. If we use git as scm it's simple to use the same nest(let's say uppsrc) and test other changes because git branches use the same location but modify content of files related to current branch.

IMO git is just great (I'm mainly on Linux, but on Windows should not be that much trouble using it) and switching to git will be a step forward for U++.

Andrei

P.S.: If you want to test git, you may use my mirror from gitorious.org, even if it's not updated i think it will help you take a decision to use git or not.
Re: GIT essentials [message #24339 is a reply to message #24338] Mon, 11 January 2010 16:13 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
those 30+ minutes... was that from (internal) main UPP SVN or from google mirror? The internal SVN is running behind ordinary ADSL line, so the upload is horrible. If you want fair comparison, you must time checkout from google's SVN. (I still bet the GIT would win, but I don't think the difference will be so huge)
Re: GIT essentials [message #24341 is a reply to message #24339] Mon, 11 January 2010 16:32 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
mr_ped wrote on Mon, 11 January 2010 17:13

those 30+ minutes... was that from (internal) main UPP SVN or from google mirror? The internal SVN is running behind ordinary ADSL line, so the upload is horrible. If you want fair comparison, you must time checkout from google's SVN. (I still bet the GIT would win, but I don't think the difference will be so huge)

Yes, you're right. It was main UPP SVN. Anyway i think git offer many more advantages than svn and you could easily mimic svn work-flow with git.
Re: GIT essentials [message #24343 is a reply to message #24341] Mon, 11 January 2010 16:42 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
I've tested with googlecode.

svn
real 5m0.305s
user 0m25.060s
sys 0m10.330s

Anyway i think it's not that much because we don't to a full checkout too often perhaps only when local repo get compromised or we checkout on a new system.

http://git.or.cz/gitwiki/GitSvnComparsion
Re: GIT essentials [message #24345 is a reply to message #24343] Mon, 11 January 2010 17:19 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
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 Smile ).

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 Go to previous messageGo to next message
andrei_natanael is currently offline  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 Smile.
Re: GIT essentials [message #24352 is a reply to message #24347] Tue, 12 January 2010 06:07 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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. Smile

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 #24355 is a reply to message #24352] Tue, 12 January 2010 09:18 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Are you sure about "Cons" and "Pros"?
Re: GIT essentials [message #24359 is a reply to message #24352] Tue, 12 January 2010 10:58 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, 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 Wink.
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 Razz

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


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 Go to previous messageGo to next message
kohait00 is currently offline  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 Smile), 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 Smile 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++ Smile. 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 312 times)
Re: GIT essentials [message #24364 is a reply to message #24360] Tue, 12 January 2010 21:28 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 680
Registered: November 2008
Location: France
Contributor
Hi I've been using HG for more than two years now and it works perfectly: fast and easy to use.
It's available under:
1. Windows
2. Mac OS X
3. Linux (.deb)
4. Linux (.rpm)
5. Linux (others)
6. Solaris
7. AIX
8. BSD

The base commands of HG are very simple and it's almost impossible to do "bad" things you can always rollback if last action was wrong.

The main GUI, TortoiseHG, has done lots of progress, is very good now and is the same under linux or windows (I haven't tried on other OSs).


I have no experience with GIT so I won't say anything about it, but does it have good GUI's ?

Anyway before changing from svn to another SCM people can try HG, and probably GIT or another SCM, by using it over SVN:
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
Re: GIT essentials [message #24371 is a reply to message #24364] Wed, 13 January 2010 05:36 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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 #24372 is a reply to message #24355] Wed, 13 January 2010 05:49 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
cbpporter wrote on Tue, 12 January 2010 03:18

Are you sure about "Cons" and "Pros"?


Sorry. Smile I shouldn't be allowed to write anything after 12pm.


Regards,
Novo
Re: GIT essentials [message #24373 is a reply to message #24359] Wed, 13 January 2010 06:40 Go to previous messageGo to previous message
Novo is currently offline  Novo
Messages: 1358
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 Wink.
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 Razz



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


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

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

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

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


Current Time: Fri Mar 29 03:36:50 CET 2024

Total time taken to generate the page: 0.02214 seconds