UFO:Alien Invasion
Development => Newbie Coding => Topic started by: Niggle on September 25, 2010, 11:53:35 am
-
Hi,
I've got the last svn code already and I notice that you've now switched to git.
Is there an easy way to switch to using the git repository without having to re-download the entire source over a 1MBit (on a good day) connection? Basically, I want to just update from the last svn version.
Nigel
-
Is there an easy way to switch to using the git repository without having to re-download the entire source over a 1MBit (on a good day) connection? Basically, I want to just update from the last svn version.
No.
-geever
-
Somebody mentioned somewhere a 'shallow fetch n' where only the last n revisions are DLed ??
-
Because this was raised
I just want to do very few things
get the source and update the source including 2.3 branch
I got the source on Fri Sep 17
Now i try to update using
git pull -v
and i have to redownload 1.6Gigs into another *.pack file on my disk
next to the already existing one
Why do i need to redownload the whole source again!
I thought!
git clone -v --progress git://ufoai.git.sourceforge.net/gitroot/ufoai/ufoai C:\path\to\somewhere
would get the whole source
git checkout master
would switch into the "current trunk"
git checkout ufoai_2.3
would switch into the 2.3 branch
git pull -v
would update the current branch (master|ufoai_2.3)
-
you should use
git fetch
git rebase '@{u}'
to not add merge commits whenever you have local changes (which might happen for some of your users)
but in general this should only fetch the diffs of course - but we fixed parts of the history recently and this affected almost everything. so either reclone the repo or see http://lists.killfile.pl/pipermail/ufoai/2010-September/001891.html to fix this.
-
Ok, now i am totally confused
Lets say i have 3 brachnes
master
ufoai_2.3
own
1)I'm on ufoai_2.3 and want to update the source
Is it necessary to checkout master first
or can i fetch from ufoai_2.3 branch
1a)would a fetch update master and ufoai_2.3 or only ufoai_2.3
2)I cant switch branches with "open" changes. Would a commit solve this
Let say i have made a small mod on master
and i want to keep this just for me (to fix|cheat|whatever)
I need to commit this to the master (bad idea) but not pushing it (a push would upload any mod?!)
This way i'm able to keep this change
even if i fetch|pull|checkout..
3)a fetch isnt an update, is it? Im getting the updates but im doing nothing with it
3a)pull --rebase would do the same as fetch & rebase?
I hope i got the whole thing right ...
The best is to make your own local branch
doing modifications there
merge this into the master and push it
Than doing changes on the master branch
right?
To update my own branch
i need to update the master branch and merge with my own branch?!
My plan is to support 3|4 branches
master
ufoai_2.3
own
own2?
master & 2.3 is self explaining
the own* branches are for modification
and the user need to handle git on its own
on the own* branches
-
1) you can call git fetch from any branch you like or from any directory in the hierarchy of your clone. fetch does not update your working copy - it only fetches the latest commits from the sf.net git repository.
and you have to call git upbase (this is an alias we have set up (see Getting the source (http://ufoai.ninex.info/wiki/index.php/Getting_the_source)) or git rebase '@{u}' from within your branch(es) to merge the new fetched commits into your working copy. Without this you only updated the index (the .git directory in the clone) but not your working copy.
1a) already answered i think
2) see the git stash feature or commit it
3) already answered i think
3a) "pull --rebase" can be used, too
if you make your own branch, you should set the tracking branch to master and just do git upbase to merge the changes from master onto your local commits
-
I wanted to just contribute. And now it is impossible to do it.
-
and the reason is? what isn't documented, what isn't working for you? it doesn't help anyone if you make statements like these.
-
Hi Matt,
Sorry to jump in on this thread but I think Kildor makes a vitally important point, which is the size of the initial download. I would contribute if I could, but my broadband connection barely achieves 512mbit on a good day and craps out on a regular basis. Large file downloads (>200mb) are nigh-on impossible to achieve in one go.
I know GIT is better than SVN for poor bandwidth connections generally, but all the same...
I have never had much luck with checking out SVNs for this project and others, but a few months back I was staying in a hotel with a ludicrously fat internet pipe and was able to try the Muton build tool (including getting hold of that >1gb download) and build the game once or twice before going home to my rubbish internet connection.
It took me a good half hour just to download the updates between build versions, even when I was doing it twice a week... and even then it would occasionally FUBAR because the internet connection wasn't stable.
I haven't updated since the start of September simply because downloading 1.6gb worth of data AGAIN (whether using Muton's tool or not) to start the ball rolling, just isn't viable on my domestic internet connection and I can't use the work connection for it either (heavily filtered).
-
it is impossible to download, to fetch, to update sources.
-
use rsync:
rsync -av ufoai.git.sourceforge.net::gitroot/ufoai/* $DIR_TO_PLACE_THE_REPO_IN
rename the directory into .git and move it into ufoai/.git
edit ufoai/.git/config and change the bare boolean to false
go into ufoai and checkout your working copy
git remote set-url --push origin ssh://USER@ufoai.git.sourceforge.net/gitroot/ufoai/ufoai
git remote set-url origin git://ufoai.git.sourceforge.net/gitroot/ufoai/ufoai
i have to admit that i've never ever tested this - but it should work, as it is a repository clone, too.
but the advantage is, that rsync can get continued
-
@Kildor:
Don't give up, don't resign !
Admittably, I'm *really* unhappy with that switch to GIT (because I couldn't work on the source for nearly a month now because of GIT).
Mattn helped me a lot, so I was able to do a few unimportant commits until everything screwed up again :(
Let's join and 'fight for the rights' of those who
- have a poor connection
- are occasional contributors (and don't want to DL 1.6 GB just to create a small patch)
- refuse to 'study' GIT and just want to code/map/whatever (ie. Tortoise users)
But let's fight for a solution *with* GIT ! (Mattn says GIT is sooo much better than SVN. I didn't notice any benefits yet, but I DO trust Mattn)
I don't know whether the solutions will be inside or outside (think: SVN-clone of GIT-repo) GIT, but I definitely know that the project will need solutions for the above mentioned problems !
Having said that, let me ask you to be more precise:
it is impossible to download, to fetch, to update sources.
*Why* exactly is it impossible for you ? Bandwidth ? Lack of GIT knowledge ? Whatever ?
-
I don`t like to stay PC for all night, but sometimes it require dozens of hours to simple fetch. And if there will be any fault, I need to restart.
Next. What`s point to work on round the clock, if «git log» simply stay on old commits? «git upbase» require from me to «edit the conflicts» in files I never touch.
And sometimes my commits just loose, and «nothing to push» (or pull, I always mix this words).
And last. The impossibility to have local changes — is evil.
PS: I do not want to learn useless information, git is useless for me. I am not a programmer and never will be. I know what ShiftDel do, and this is easily for me.
-
let me rephrase Kildor, you are saying the devs should not use dev-tools because the none-devs (or those you refuse to learn something new) are not able to handle the dev-tools? so we all have to stay in the last century for this reason? from the dev point of view git is a lot more advanced than svn and really can help us to improve the build/development process. i understand that this is new and learning something new is often time consuming. but trust me, it's worth it. once you got the hang of it, it's quite easy to handle, too.
don't give up and don't be upset - if you need help, let us help. but you have to tell us the exact problem. error messages, commands you did and so on. we are still at the start of the git conversion and i think that things will improve over time. there will hopefully soon be a some local hook scripts that will make dev- and contributors life a little bit easier, too.
anyone tried the rsync method? in theory you should not need to run the PC the whole night, in theory you should be able to continue the git download by entering the same (rsync-)command again.
-
I`ll wait until «git-conversion» will be finished. May be at winter?
And will rsync helps to update repo?
Really, it is funny first day, or two. But when this happen all month — it is a bit annoying.
-
For my part there are two issues that could be addressed:
1. Imagine you were someone who doesn't know the first thing about SVN or GIT... and you went here: http://ufoai.ninex.info/wiki/index.php/Download (http://ufoai.ninex.info/wiki/index.php/Download). Compare and contrast, to the relatively painless, user-friendly walkthrough that Muton's build tool had going for it.
2. IMHO, the availablility of UP-TO-DATE playable dev builds for people who aren't developers, has totally dropped off the agenda since you switched to GIT.
Only a couple of weeks ago, there was someone complaining about RF bugs in the 2.3 game (which had been done to death). That person got given a response along the lines of, "download the source and fix it yourself".
We all knew there were builds out there that resolved that particular bug, begging the question why doesn't someone just update the OFFICIAL download link with a more recent release candidate, instead of mocking every poor noob who's only doing what I'd expect any newcomer to do in the first instance, i.e. download the game from the OFFICIAL link, play it, and report their findings on the forum instead of trawling through the forum for a nightly build and giving that a go?
FWIW I compiled 2.4 from the last SVN, and I've been handing it round the office to them as wants to play the game, and feedback's been great. But since we don't have occasional Muton prebuilds anymore and my build's now a month past its sell-by date, and I've been told there's no point offering that for download to anyone who's interested, what's the plan?
Is this game being developed for gamers, as well as programmers?
-
I am sorry, this comment is out of scope.
Sorry i dont see the point 1. Both Git and SVN are for devs. Kildor is a dev. Yes it is harder for non coder to use Git, anyway we want to use more branches, more merges... then Git is really need. The conversion SVN->Git create at least 3 big problem which make Kildor sad (and me, and maybe every body). Anyway it is need.
2. That's not really our problem, i explain, we never officially maintain it. Only the community do this painful job. If they dont have time to maintain build, to download the new source code, we dont have any more time to do it for them. Anyway we are working on a nightly build bot for all OS + build map + unittest + installer... and so on. Then we know it is a need, and we have all hands on this problem.
And then in few times we should have more 2.4-dev release... every... night?
-
anyone tried the rsync method? in theory you should not need to run the PC the whole night, in theory you should be able to continue the git download by entering the same (rsync-)command again.
Haven't tried myself but if anyone wants to try you should add the option --partial-dir=$DIR_TO_PLACE_TEMP_FILES_IN to the rsync command given by mattn -- there are some big *.pack files in the repo (I know at least one is around 3 gigs) without this option rsync will download whole files wich means that if it's interrupted in the middle of downloading a big file it will start downloading it from the begining the next time rsyn is called -- with this option it should resume from where it was interrupted last time
(other option of interest may be --progress)
-
Alright, here's a simple question:
With SVN, it was relatively easy to download just the 2.3 branch, or just the 2.2.1 branch.
It was relatively easy to switch between the 2.3 and 2.2.1 branch for a long time; eventually, due to problems with the (then-out-of-date svn tool on Mac os 10.5.8) svn program, it was easier to just have two separate directory trees.
But I never had to worry about downloading the stuff I didn't want.
I could make local modifications, and generally they would work fine as new updates were fetched; when conflicts were found, it was fairly loud.
How would I go about only fetching just the 2.3 stuff with git, assuming
1: I have git, and
2: I've never touched it yet
How would I go about switching between the 2.3 branch and the trunk? What if I wanted to deal with the 2.4 branch when it is eventually tagged as such?
How are my local modifications handled? How are conflicts handled? How does rewinding to an earlier version, and back again, work? (This is where the version on Mac 10.5.8 stank. )
What if I wanted to take pieces from 2.3 and pieces from 2.4?
Or, equally, pieces from 2.2.1 and pieces from 2.3?
(Actually, that last one is probably not a Git question, 2.2.1 probably doesn't exist in git.)
-
it is impossible to have local changes and update sources. you must commit (or slash, or do other magic commands) before each update.
-
it is impossible to have local changes and update sources
Are your sure? git fetch + git upbase will do the job, no ?
-
Bayo,
I'm a developer too and TBH I'm on a learning curve with GIT. But I don't have an internet connection capable of grabbing the 1.6GB needed to even USE it right now, so for me the problem is utterly academic. Several months ago, I had a whole 10mbit pipe at my disposal for the day and it was heavily restricted but I was still able to grab the whole with one http download - and that's how I got started.
Next time I'm in a hotel with a 10mbit pipe, you can be sure I will start working with GIT and will download the entire repository, and from that point on it will be easier to manage. Assuming of course that they don't have heavy internet filtering, proxy servers, firewall rules etc all conspiring against me... But I might not get that chance till Christmas.
Question: How can you be sure the developers are capturing all the bugs in 2.3 (until 2.3.1 is released) or 2.4, if people actually playing the game are dependent on playing a SVN build that's now over a month old?
If all you're hearing from non-technical players is retread (like "reaction fire" complaints) then they're not able to help you and you're not able to help them. If you want them to provide meaningful feedback they have to be able to play something that is at least VAGUELY up to date.
Nightly builds are over the top, but it shouldn't be a great hardship to post fortnightly builds of 2.3 in the runup to 2.3.1 coming out, start doing monthly downloads of 2.4 after 2.3.1 comes out. If you don't, then what I suspect will happen is that 2.3.1 will come out to a great fanfare, and you'll be swamped by people reporting bugs you never knew about because the GAMERS weren't playing the dev builds
-
For my part there are two issues that could be addressed:
1. Imagine you were someone who doesn't know the first thing about SVN or GIT... and you went here: http://ufoai.ninex.info/wiki/index.php/Download (http://ufoai.ninex.info/wiki/index.php/Download). Compare and contrast, to the relatively painless, user-friendly walkthrough that Muton's build tool had going for it.
2. IMHO, the availablility of UP-TO-DATE playable dev builds for people who aren't developers, has totally dropped off the agenda since you switched to GIT.
Only a couple of weeks ago, there was someone complaining about RF bugs in the 2.3 game (which had been done to death). That person got given a response along the lines of, "download the source and fix it yourself".
We all knew there were builds out there that resolved that particular bug, begging the question why doesn't someone just update the OFFICIAL download link with a more recent release candidate, instead of mocking every poor noob who's only doing what I'd expect any newcomer to do in the first instance, i.e. download the game from the OFFICIAL link, play it, and report their findings on the forum instead of trawling through the forum for a nightly build and giving that a go?
FWIW I compiled 2.4 from the last SVN, and I've been handing it round the office to them as wants to play the game, and feedback's been great. But since we don't have occasional Muton prebuilds anymore and my build's now a month past its sell-by date, and I've been told there's no point offering that for download to anyone who's interested, what's the plan?
Is this game being developed for gamers, as well as programmers?
Well, doing it myself ended with an error called queue=qtrue, so i've stopped there.
-
we are also working on automated builds (nightly builds) with a buildbot instance. just stay tuned a little bit...
-
Here you have the first binary snapshot from 2.4-dev for Windows
http://ufoai.ninex.info/wiki/index.php/Download
It not contain resources or compiled maps, and not uforadian
But it is more and more out of topic...
-
> Are your sure? git fetch + git upbase will do the job, no ?
No. git fetch annoys me about «uncommited changes». And this is shit, because I don`t want to commit this changes to main repo at all.
-
git fetch <--- download latest changes and put them into your local repo
git stash save <--- save your changes but make your working copy clean
git upbase <--- update your workingcopy
git stash pop <--- restore your local changes
btw. which changes are needed in your local copy but should not get commited? something build related?
-
git fetch <--- download latest changes and put them into your local repo
git stash save <--- save your changes but make your working copy clean
git upbase <--- update your workingcopy
git stash pop <--- restore your local changes
I already whined about stashing in the Coding forum:
http://ufoai.ninex.info/forum/index.php?topic=5413.0
btw. which changes are needed in your local copy but should not get commited? something build related?
I often modify the code just for debugging purposes.
Also, as I tend to work on several bugs and/or features simultaneously, there is always quite a lot of unfinished work...
Maybe the buildbot should also provide nightly source-zips ?
-
> btw. which changes are needed in your local copy but should not get commited? something build related?
* Unfinished maps that I don`t want to share yet (is not enough quality).
* Some playing with ump (again unfinished).
* normal version of compile_maps.bat (I hate current version of it).
* some others tests, playings and so on.
-
just stash them away (a simple script like:)
#!/bin/sh
cd /path/to/ufoai
git fetch
git stash save
git upbase
git stash pop
-
@duke: about working on single bugs - there is nothing wrong in doing one local branch for each bug. switching branches, merging branches - stuff like that is a lot faster and more advanced compared to svn.
the problem with .cproject and .project is not related to stashing. you would have the same problem when doing svn up - a merge conflict is a merge conflict. we have to think about a solution for these files - but for this we have to get eclipse + mingw working for windows first (which i'm still working on btw)
-
* Unfinished maps that I don`t want to share yet (is not enough quality).
These shouldn't create any problems as long as you haven't comitted them locally. I also have unfinished maps in the directory.
* Some playing with ump (again unfinished).
Yeah, this will cause a problem. You could rename the file to "(mapname)_test.ump" and then add a new .ufo file that points to (mapname)_test, so you have both the trunk and the modified version as options in skirmish.
* normal version of compile_maps.bat (I hate current version of it).
I just renamed mine to compile_maps_old.bat and I run that instead when I need it.
-
> btw. which changes are needed in your local copy but should not get commited? something build related?
* Unfinished maps that I don`t want to share yet (is not enough quality).
* Some playing with ump (again unfinished).
* normal version of compile_maps.bat (I hate current version of it).
* some others tests, playings and so on.
My oppinion is: you should create local branches for these and commit on top of them.
-geever
-
I have not worked with Git (yet)
But I hope to get rid of all my unversioned files and changes. These things should go into a local branch.
@duke: as Mattn proposed one local branch per bug seems appropriate.
-
@duke: as Mattn proposed one local branch per bug seems appropriate.
I believe you and Mattn that this is the way to go with GIT.
But isn't that trading stashing for branching ?
My point is that it's *overhead* compared to SVN. I don't want to manage branches, I want to squash bugs.
-
What do I do that doesn't get committed?
Debugging builds trying to track down the graphic issues (although I've got a new idea to try to track it down, that goes back to the older stuff in svn)
Modifying the make scripts to make sure that there's a locally compiled map ready when I type "make".
At one point, when I had some files on an external drive for space reasons, I had some symbolic links and needed to modify some "find" commands in the makefiles to include (I think) -L
Sometimes I've had to play around with configure.
Branches
With SVN, I could make a local modification (such as to the Makefiles, or debugging output in the renderer), and then move around from revision to revision, and my changes stay in. So if I'm trying to track something in rendering, I can.
The point is?
It sounds like the only way to play with git is to commit everything that you do.
That sounds like saying that you have to allow anyone that wants to play with the source to commit changes to the development tree.
Unless I'm missing something, that's horrible.
What is supposed to be git's benefit over svn?
-
a commit is not going to become part of the development tree on sf.net - you still have to publish it (push it).
you can always stash your local working copy changes besides, checkout the revision you like to have, and pop back your stashed changes into your current working copy (this is btw. nothing git specific, it's the same for mercurial and the like, too)
if you try to nail down a revision that introduced a bug, you should try the git bisect feature.
-
one more note maybe. we don't have to allow anything to anyone on the local git repo clone. it's a repository everybody on the world can cherry-pick or clone from again. what we have to allow is the pushing of your commits back into the sf.net repository. you can make as many commits as you like in your local copy, or create as many branches as you like.
-
But isn't that trading stashing for branching ?
I don't think so.
With stashing all your changes are in one place, you risk publishing unfinished code and one bugfix affecting an other one.
With branching you separate the changes for each task, with regular commits to the branche you reduce the risk of loosing your codechanges with awrong delete, edit or merge, you can use all the tools git provides for the code you develop (changehistory, bisect, ...) and you can even "ignore" the changes in the masterbranch (but if you wait to long mergin the changes back will be painful)
My point is that it's *overhead* compared to SVN. I don't want to manage branches, I want to squash bugs.
Yes it is overhead. All I can do is to urge you to try branching (and if it does not work for you at the moment to try it again, when you are comfortable with git) and then decide if it's worth it.
-
The point is?
It sounds like the only way to play with git is to commit everything that you do.
That sounds like saying that you have to allow anyone that wants to play with the source to commit changes to the development tree.
Unless I'm missing something, that's horrible.
Well SVN is a VCS and Git is a DVCS (distributed version control system)
As Mattn pointed out, the commits are on your mashine. Unles you push them to an other repository or someone fetches/pulls them from you, nobody else is affectet.
What is supposed to be git's benefit over svn?
The "distributed" part in DVCS gives the administrators of the repository additional freedom to tailor the way the repository works to the development process. That won't matter for you but it can relieve the main developers of a lot of work.
An other benefit that depends on the circumstances you work in is, that you have (a part of) the repository on your mashine and you don't have to be connected to the server to work with the repository. (view code, change branches ...)
And you can commit your changes to the local repository and use all the tools git provides for your code development.
Actualy the last one is the important one for me. And if you don't know the tools git provides for you should start to explore your new posibillities
-
@muton and everyone: can i get a newest make_ufoai_win32.exe? My old hdd lost the file.
-
What for?
Its broken!
but .... make_UfoAI_win32.exe (http://www.meduniwien.ac.at/user/michael.zellhofer/ufoai/make_UfoAI_win32.exe)
-
how did it break?
-
it doesn't support GIT (yet? ;))
-
so fix it ;D
-
so fix it ;D
A bit easier said than done, I'd think.
I noticed that there are portable versions of the Git software for Windows, I would imagine that with some work that could be used in a new package, but Muton would really have to answer that.
-
Yeaa, Git looks not very good for Windows.
-
Yeaa, Git looks not very good for Windows.
I have to agree - I think the move from SVN to Git was a mistake, one that really shafted potential and current Windows developers, and I agree with Kildor's viewpoint on the matter.
Git is only partially working software, clunky and buggy as hell on the Windows platform. Myself, I can get the portable Git working but the Tortoise Git corrupts Windows Explorer on my system and makes my Windows installation very unstable - I was forced to erase the hard drive and restore everything from a backup.
I should have spoke up about this before, but the move to Git really should have been planned better and researched before being done, so that the coders would realize that much of the Git system hasn't been implemented at all on Win32 (many commands not yet supported), and the move is a rather bad mistake.
As of right now I still can't commit any updates, and I have issues just updating a downloaded "working" copy.
I won't threaten to leave this project, but this poor decision really is a big shot in the ass for Windows people, and will drive away many people who would want to become developers or contributors.
Before any of you coders respond to that, please keep in mind that the vast majority of people who have and use computers use Windows - just look at the stats. Very few people really use Linux, which is really the only OS I know of where Git really works very much at all. If I didn't know better, I'd almost say this move to Git was made by a bunch of Linux-heads who don't care about the majority of people who use Windows and feel that all the Windows guys may as well go do something to themselves.
SVN on Windows has become mature and on all my computers is fairly rock-solid, not only with Tortoise SVN, but other apps I tried as well.
Git, on the other hand - Well, I just can't recommend this godawful rubbish Git software to anyone, unless they are working on a Linux-only software project that isn't applicable for Windows.
If we had waited until Git was actually working for Windows, until it became mature, that would have been different.
Last, I *still* fail to see any real benefit of moving to Git, so far it has only f***ed things up. The decision should have been planned, thought out, and researched better.
-
At my work i install msysgit to check it. And now when i work with Java iv got very strange error message like "fatal: Not a git repository (or any of the parent directories): .git". Kind of message really out of the scope from what i am doing. Anyway i dont care, i can uninstall it when i want, but this software is really not yet ready.
*still* fail to see any real benefit
As it is already said, u dont need to use branches, or merge thing, or do some advenced things like that, then you will never see any benefit :-) But it can help you for debuging.
-
Also, git doesn't support resume for fetch and clone and cann't be suitable for such big repository as this.
-
Should we start a poll and dedicated thread on what would be a better choice?
Sourceforge supports a number of different version controls systems, not just Git and SVN.
Whatever we use, I think it would make more sense to use something that's mature in development - something that has been around for a while and not something new - and has stable, rock-solid implementation and full support on all major Operating System platforms.
-
i agree, the svn was better, because there is muton's tool.
-
+1 we should use CVS
-
I want to break a lance for Mattn
The move to git was the right thing to do
Merging code is a torture under svn
merging a fork is :P
The older MsysGIT was bugged the new 1.7.? does its job
and adding Git was not a software problem.
Its a Layer8 problem, but thats normal for a Svn->Git move
I stuck because i dont know what mattn is doing/planing
C::B support seems to be dropped and native MinGW compiling isnt possible
-
I want to break a lance for Mattn
The move to git was the right thing to do
Merging code is a torture under svn
merging a fork is :P
The older MsysGIT was bugged the new 1.7.? does its job
and adding Git was not a software problem.
Its a Layer8 problem, but thats normal for a Svn->Git move
I stuck because i dont know what mattn is doing/planing
C::B support seems to be dropped and native MinGW compiling isnt possible
Well, even if the old system made merging a pain, the new one seems worse - not only can I still not commit any changes yet (I'm still fighting with this awful software), but I can't even get a read-only copy to update once in a while. Even if I don't make any commits or changes at all, it will only update once or twice before bombing with errors and becoming useless, forcing me to delete the whole directory and re-download the whole thing again. I've tried everything from fetch, to rebase, to pull, to using other third-party "helper" utils and I still can't make it work. Oh, and BTW, yes, I have been reading guides and documentation, so I'm not some ignorant character who can't make it work simply because they don't read instructions.
There are other alternatives that SF servers support, for example Mercurial, although I admit I haven't researched all of them - but there's much more than just SVN, CVS, and Git.
I'm really hoping Mattn will read this thread and soon tell us what the game plan will be. Yes, I've also noticed the Windows compiling/build and other support really go down the toilet recently. The move to Git is just another example of this trend.
-
I use Windows and have no problem using the Gitbash interface that comes with whatever it is we were told to download (msysgit I think, but the program is called GitBash on my system - shows you how little I know about this stuff). You're right, TortoiseGIT is not really mature yet, but you don't need it either. It does the few things that it's really helpful for Windows users to have (selecting several different files in a folder rather than performing adding via command line, for instance). The rest is just as simple (actually, I would say more simple) via the command line interface: fetching and pushing. I use TortoiseGIT as little as possible (basically, I add new files and create a commit only with it).
For artists -- whether sound, model or mapping -- distributed control systems like this are often much more complicated than needed, for the simple reason that it's unlikely that one person will be working on the reverb while another completes the guitar riffs, or I will be painting the head on a body model while someone else paints the shoes. We don't need simultaneous access to single files and a system that can manage simultaenous changes. But that's exactly what the coders need, and for that merging and all the other stuff is incredibly important.
Yes, I've also noticed the Windows compiling/build and other support really go down the toilet recently.
Of course when a major change like this happens that renders several tools non-functioning, it will take a while to bring them back up to speed. The same thing has happened in non-Windows areas, like the web-based info on licensing used for GPL'ing textures, the map-get.py script, etc. Yet many of them are already back online, and entirely new build systems are being put in place now.
-
+1 SVN
-
i don't think the git move was wrong. and i don't think git is bugged or anything like that, i'm using the official git installer and it works fine on win32.
also the git move was researched before. i've looked at some other dvcs before we decided to use git. for those of you who are "only" fetching the latest dev version from the repo: you don't even have to compile (use the nightly build binaries), nor checkin - so where is the problem? and yes, maybe some of you find svn easier than git - but a vcs is there to support the devs - and git is more advanced than svn to help every dev who knows how to handle it. i've never said it wouldn't need some learning - but i've always said that it's worth it.
also i don't see why this step should screw new contributors? getting the source, creating a patch, submit a patch. it's in no way different from the svn workflow, isn't it? (it's just git format-patch and not svn diff)
-
@Muton: C::B is not yet dropped, but i would like to drop it. what is the exact problem with mingw compilation? (or is it "only" about the static libs?)
-
i've checked in a c::b project file that works with the makefiles in the background - just make sure your sdl-config is returning the correct path for sdl-config --cflags - in the c::b package we offer for download it points to dave's home dir - which will of course fail for everyone else. If you get a SDL_opengl.h not found error, this is due to the wrong path in sdl-config
-
Please read this:
http://ufoai.ninex.info/forum/index.php?topic=5435.msg43566#msg43566 (http://ufoai.ninex.info/forum/index.php?topic=5435.msg43566#msg43566)
-
use rsync:
rsync -av ufoai.git.sourceforge.net::gitroot/ufoai/* $DIR_TO_PLACE_THE_REPO_IN
rename the directory into .git and move it into ufoai/.git
edit ufoai/.git/config and change the bare boolean to false
go into ufoai and checkout your working copy
git remote set-url --push origin ssh://USER@ufoai.git.sourceforge.net/gitroot/ufoai/ufoai
git remote set-url origin git://ufoai.git.sourceforge.net/gitroot/ufoai/ufoai
i have to admit that i've never ever tested this - but it should work, as it is a repository clone, too.
but the advantage is, that rsync can get continued
receiving incremental file list
rsync: send_files failed to open "/ufoai/ufoai/objects/pack/pack-cc998cb5595939311e254e994c9f6edf4317a739.keep" (in gitroot): Permission denied (13)
Is it normal and I can exclude this file?
Also, after `git remote set-url origin git://ufoai.git.sourceforge.net/gitroot/ufoai/ufoai` I got "fatal: No such remote 'origin'"