It would be nice to convert our launchpad bazzar to gitZ-Man wrote:Probably not. How the project is shared is of very little importance. I'd just throw it all into git.Word wrote:Would it speed things up if you do that?
git (split from New Engine Please)
- kyle
- Reverse Outside Corner Grinder
- Posts: 1876
- Joined: Thu Jun 08, 2006 3:33 pm
- Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
- Contact:
git (split from New Engine Please)
Re: New engine please
WAY TO GO KYLE YOU WOULD POST ON 9/11!kyle wrote:It would be nice to convert our launchpad bazzar to gitZ-Man wrote:Probably not. How the project is shared is of very little importance. I'd just throw it all into git.Word wrote:Would it speed things up if you do that?
(If you take this seriously I will giggle forever.)
- kyle
- Reverse Outside Corner Grinder
- Posts: 1876
- Joined: Thu Jun 08, 2006 3:33 pm
- Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
- Contact:
Re: New engine please
what about migrating the SVN on sourceforge (or is that corrupt) to git, and then any subprojects would just have to be reimplemented from their parent?
Re: New engine please
That's another possibility; it has its own downsides. On the upside, we'd get mergeable 0.4 and 0.2.8 with probably full history. How much the move operations Luke-Jr did back then affect things is unknown, but I started the process (aborted it because it took too long) and it did not seem to have fundamental problems with it.
The downsides I know about: It's a one way trip; you can't really sync git back to svn. If you have a change in git, push that to svn and pull it back to git, it has changed signature. So everyone would have to switch to git at once. Again, I would not object to that. But it would affect the foreign branches; bzr 0.2.8 would no longer get updates, so the stys would go stale and would have to somehow migrate to git. I have not investigated whether there may be a clean path for them. Maybe bzr->git conversion and some sledgehammer work gets them into a state where they can pull future changes from git.
So the procedure there would be: Set up a one-way sync from svn to an otherwise readonly git repository, see how that goes, give everyone who cares a bit of time to adapt their private branches to git, and then at some later time disable the syncing, declare bzr and svn dead and have everyone switch.
Tiny problem for us: 0.2.8.3 security updates still need to be built from svn. But those things need heavy manual care that fixes merge correctly anyway, I can use diff and patch to manually haul them over to git just fine.
The downsides I know about: It's a one way trip; you can't really sync git back to svn. If you have a change in git, push that to svn and pull it back to git, it has changed signature. So everyone would have to switch to git at once. Again, I would not object to that. But it would affect the foreign branches; bzr 0.2.8 would no longer get updates, so the stys would go stale and would have to somehow migrate to git. I have not investigated whether there may be a clean path for them. Maybe bzr->git conversion and some sledgehammer work gets them into a state where they can pull future changes from git.
So the procedure there would be: Set up a one-way sync from svn to an otherwise readonly git repository, see how that goes, give everyone who cares a bit of time to adapt their private branches to git, and then at some later time disable the syncing, declare bzr and svn dead and have everyone switch.
Tiny problem for us: 0.2.8.3 security updates still need to be built from svn. But those things need heavy manual care that fixes merge correctly anyway, I can use diff and patch to manually haul them over to git just fine.
Re: git (split from New Engine Please)
Right. FOR EXPERIMENTS ONLY, I let the whole process as described in kyle's link run through on my server. Worked like a charm. Results are here:
http://vps-zman.armagetronad.org/~manue ... tronad.git
Clone it with
Code is then in armagetronad/armagetronad.
This is certainly not something we will keep. The email addresses are wrong because I screwed that bit up, an update is running. (Edit: That bit is done now) It's almost certainly going to change once again, because
Poll: For those who committed directly to SVN, how would you like your name to appear in git should we make the switch? Right now, you're all "user <user@users.sf.net>".
The basic structure of the repository is final, though, at least if I should be our migration manager. Anything but the standard import from svn, keeping its structure, is just going to cause massive headaches. So, for those who don't want to clone the repository to check it out:
It's ALL of our stuff related to the game itself. All branches, all subprojects. So, you'll be getting winlibs whether you need them or not. It's not as bad as it sounds, the revision data is just a tad over 60 Mb.
I don't know whether I'll bother setting up automated updates to current SVN revisions.
The question, of course, is: would there be demand for a switch? I'm generally content with bzr in itself, my gripe is just that we can't merge from 0.2.8 to 0.4 and the corruption on 0.4 I don't know how to repair. And I like the increased flexibility I have when combining bzr braches, that made tasks like building 0.2.8.3 builds for zeroinstall a lot easier.
http://vps-zman.armagetronad.org/~manue ... tronad.git
Clone it with
Code: Select all
git clone http://vps-zman.armagetronad.org/~manuel/git/armagetronad.git armagetronad
This is certainly not something we will keep. The email addresses are wrong because I screwed that bit up, an update is running. (Edit: That bit is done now) It's almost certainly going to change once again, because
Poll: For those who committed directly to SVN, how would you like your name to appear in git should we make the switch? Right now, you're all "user <user@users.sf.net>".
The basic structure of the repository is final, though, at least if I should be our migration manager. Anything but the standard import from svn, keeping its structure, is just going to cause massive headaches. So, for those who don't want to clone the repository to check it out:
It's ALL of our stuff related to the game itself. All branches, all subprojects. So, you'll be getting winlibs whether you need them or not. It's not as bad as it sounds, the revision data is just a tad over 60 Mb.
I don't know whether I'll bother setting up automated updates to current SVN revisions.
The question, of course, is: would there be demand for a switch? I'm generally content with bzr in itself, my gripe is just that we can't merge from 0.2.8 to 0.4 and the corruption on 0.4 I don't know how to repair. And I like the increased flexibility I have when combining bzr braches, that made tasks like building 0.2.8.3 builds for zeroinstall a lot easier.
Re: git (split from New Engine Please)
I find it much more comfortable to work with git (or with a decentralized version control system in general). I like doing my commits locally first and push everything when things are working.Z-Man wrote:The question, of course, is: would there be demand for a switch? I'm generally content with bzr in itself, my gripe is just that we can't merge from 0.2.8 to 0.4 and the corruption on 0.4 I don't know how to repair.
What do you mean exactly with combining? Like resolving dpendencies for external libs? Would git submodules work for that?Z-Man wrote:And I like the increased flexibility I have when combining bzr braches, that made tasks like building 0.2.8.3 builds for zeroinstall a lot easier.
Re: git (split from New Engine Please)
Combining outside of the source control. I'd get a clone of the bzr branch 0.2.8-armagetronad-work and 0.2.8-build-work, side by side. Then I can use 0.2.8-build-work to make a release build of 0.2.8-armagetronad-work. So far, so normal; I can do that in git simply in the subdirectory 'build'. But with the bzr branches, I also combined 0.2.8-build-work with ap or ctsty and make builds of that. Or svn checkouts of 0.2.8.3.3. I guess the 'combining' is less the thing I use here, more lightweight checkouts of parts of a project. Natively possible in svn, made possible by our branch structure in bzr.Jip wrote:What do you mean exactly with combining? Like resolving dpendencies for external libs? Would git submodules work for that?
Of course, that's all basically a 'me' problem And I could solve it by putting the build/release stuff in a separate repository.
- kyle
- Reverse Outside Corner Grinder
- Posts: 1876
- Joined: Thu Jun 08, 2006 3:33 pm
- Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
- Contact:
Re: git (split from New Engine Please)
Yes, you could fork it for those , and then set 2 remote "origins" to merge in stuff as needed from the main origin. That's how i would intend on having sty+ct set up, In theory it should work anyway. I was thinking you could use this git repository on launchpad, then you could still sync with the svn on sourceforge? But before you do anything too major, I'd like to see if it is simple to fix the broken branch. since that would be much cleaner for the current forks
EDIT: also need a .gitignore
EDIT: also need a .gitignore
- Lucifer
- Project Developer
- Posts: 8641
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Re: git (split from New Engine Please)
I don't know anything about git except that it's a different program that soves the same problems bzr solves.
To ake the migration, I'd need a lot more than "it's more comfortable to me" or "I like it better". I need real reasons besides "it's better than bzr." There are a lot of ways at looking at things, so I need solid facts that show that git is better for what we do than bzr.
In much the same way that you, Z-man, needed solid facts that showed that bzr was better than svn. There will be a cost to it that we don't know about right now (same as with the svn to bzr change), and we need something that will show that the cost is worth spending because the benefit we get is so awesome.
My current understanding of git vs bzr is that they're so similar and they solve all the same problems in such a way that there's likely no cost that's worth absorbing. If you're already on bzr, there's no point moving to git, and vice versa.
To ake the migration, I'd need a lot more than "it's more comfortable to me" or "I like it better". I need real reasons besides "it's better than bzr." There are a lot of ways at looking at things, so I need solid facts that show that git is better for what we do than bzr.
In much the same way that you, Z-man, needed solid facts that showed that bzr was better than svn. There will be a cost to it that we don't know about right now (same as with the svn to bzr change), and we need something that will show that the cost is worth spending because the benefit we get is so awesome.
My current understanding of git vs bzr is that they're so similar and they solve all the same problems in such a way that there's likely no cost that's worth absorbing. If you're already on bzr, there's no point moving to git, and vice versa.
Re: git (split from New Engine Please)
A couple years ago I watched Linus Torvolds give a Google Talk on GIT and thought it was really interesting.
Re: git (split from New Engine Please)
Well, I'm not the right person to convince Lucifer. I'm not sold on it myself. "I would not object" is really as far as my enthusiasm goes Here is my score breakdown:
+ git: has 'git rebase'. 'bzr rebase' was killed.
+ git: faster.
- git: bzr uses less disk space.
+ git: multiple branches in one working directory (repository) allow more workflows.
- git: that makes the interface for common operations more complicated and it's harder to know what the actual state of your working directory is.
- git: does not properly track file renames
+ git: isn't anal about merging two commits that add the same file and can track content moves from file to file. That bzr assigns each file a unique ID is what prevents merges from 0.2.8 to 0.4.
+ git: merges seem to make more sense.
+ git: has 'git rebase'. 'bzr rebase' was killed.
+ git: faster.
- git: bzr uses less disk space.
+ git: multiple branches in one working directory (repository) allow more workflows.
- git: that makes the interface for common operations more complicated and it's harder to know what the actual state of your working directory is.
- git: does not properly track file renames
+ git: isn't anal about merging two commits that add the same file and can track content moves from file to file. That bzr assigns each file a unique ID is what prevents merges from 0.2.8 to 0.4.
+ git: merges seem to make more sense.
- kyle
- Reverse Outside Corner Grinder
- Posts: 1876
- Joined: Thu Jun 08, 2006 3:33 pm
- Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
- Contact:
Re: git (split from New Engine Please)
I pretty much so agree with what z-man said except, this one
then I addition from what I have used it for
+git, cherrypick merging a little more sane and user friendly
+git staging files to commit (You can save your debug statements or partially implemented code for a latter commit)
-git, learning curve for complexities
+/-git a few different GUI's can help with the more complex features
Still maybe annoying, but I believe it tracks it properly is you use git mvZ-Man wrote:- git: does not properly track file renames
then I addition from what I have used it for
+git, cherrypick merging a little more sane and user friendly
+git staging files to commit (You can save your debug statements or partially implemented code for a latter commit)
-git, learning curve for complexities
+/-git a few different GUI's can help with the more complex features
- compguygene
- Adjust Outside Corner Grinder
- Posts: 2346
- Joined: Thu Aug 21, 2008 12:09 pm
- Location: Cleveland, Ohio
- Contact:
Re: git (split from New Engine Please)
I was curious to see what a google search would yield up comparing the two CVS systems and came up with these two intriguiging articles.
bzr is dying; Emacs needs to move
and
BAZAAR-NG: 7 YEARS OF HACKING ON A DISTRIBUTED VERSION CONTROL SYSTEM
Both of these articles are stating that bzr has had very little development since 2013.
bzr is dying; Emacs needs to move
and
BAZAAR-NG: 7 YEARS OF HACKING ON A DISTRIBUTED VERSION CONTROL SYSTEM
Both of these articles are stating that bzr has had very little development since 2013.
Both articles are also pointing out that at this time most of the big open source projects have moved to git. But, the biggest thing that I see as an advantage to consider is this:< ddaa> There are two kinds of dscms... the obsolete ones and the experimental ones
To me, if git is going to make it more likely that we can attract new talent to contribute to the project, that is huge.In practice, I judge that sticking with bzr would have social and
signaling effects damaging to Emacs's prospects. Sticking to a
moribund version-control system will compound and exacerbate the
project's difficulty in attracting new talent.
The uncomfortable truth is that many younger hackers already think
Emacs is a dinosaur - difficult, bulky, armor-plated, and generally
stuck in the last century. If we're going to fight off that image, we
cannot afford to make or adhere to choices that further cast the
project as crusty, insular, and backward-looking.
As of right about now, continuing with bzr is such a choice. We'll
lose potential recruits, not merely because bzr has a learning cost
but because crusty, insular, etc. The opportunity cost of not getting
out will only rise with time.
git won the mindshare war. I regret this - I would have preferred
Mercurial, but it too is not looking real healthy these days. I have
made my peace with git's victory and switched. I urge the Emacs
project to do likewise.
Armagetron: It's a video game that people should just play and enjoy
https://bit.ly/2KBGYjvCheck out the simple site about TheServerPharm
https://bit.ly/2KBGYjvCheck out the simple site about TheServerPharm
- kyle
- Reverse Outside Corner Grinder
- Posts: 1876
- Joined: Thu Jun 08, 2006 3:33 pm
- Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
- Contact:
Re: git (split from New Engine Please)
Git alone may not, moving off of sourceforge to github, most likely will, but small steps Most projects have left soruceforge because it's become an adware distributor, I think they have reverted some of this, but the damage was already done.compguygene wrote:To me, if git is going to make it more likely that we can attract new talent to contribute to the project, that is huge.
Re: git (split from New Engine Please)
Ah? Ok!kyle wrote:I pretty much so agree with what z-man said except, this oneStill maybe annoying, but I believe it tracks it properly is you use git mvZ-Man wrote:- git: does not properly track file renames
A little more sane may not be quite enough They don't track the revisions that were merged. Of course, with git's lenient merges, that does not matter much.kyle wrote:+git, cherrypick merging a little more sane and user friendly
compguygene: Yeah, those reports of emacs switching were what triggered my investigation.
We're essentially only using sf for downloads; but that may actually be our biggest legacy system problem. The adblocker I use here COMPLETELY blocks sourceforge by default.kyle wrote:Most projects have left soruceforge because it's become an adware distributor, I think they have reverted some of this, but the damage was already done.
I managed to repair our broken 0.4 branch! The defect is only in one revision on the mainline. Here are the commands:
Code: Select all
# fetch 0.4
bzr branch lp:armagetronad/0.4 || exit
# branch last good revision
bzr branch 0.4 0.4_stitched -r 795 || exit
# stitch merge: merge broken revision, but just the content.
pushd 0.4_stitched || exit
bzr merge ../0.4 -r 796 || exit
# forget merge details
bzr revert --forget-merges || exit
bzr commit -m "Re-doing merge of utf8 branch, forgetting about broken details"
# export the history up to that point, storing marks
bzr fast-export --export-marks=../marks > ../0.4_stitched.bzr || exit
# switch to full branch
popd || exit
pushd 0.4 || exit
# export rest of history, taking care not to recycle old marks
bzr fast-export --import-marks=../marks -r 796.. >> ../0.4_stitched.bzr || exit
# create import
popd || exit
mkdir import || exit
pushd import || exit
bzr fast-import ../0.4_stitched.bzr || exit
popd
1. The result is not merge compatible with 0.4.
2. The result is not sync-compatible with svn.
3. The result is still not merge-compatible with 0.2.8.
1 and 2 were to be expected, the history is broken. I looked everywhere for the missing data and could not find it, so we will have to rewrite history, and that goes with breaking merges. So we need to fix 3. It's of course possible to mash 0.2.8 and 0.4 together, but the history from 0.4 then only exists for historic value and has no practical application. I'll experiment a bit more with fastimport.
On the plus side, it should be possible to continuously pull progress from the broken 0.4 branch into the so-fixed branch. So we would not automatically lose our 0.2.8 to 0.4 merge path, it just gets two steps more complicated. bzr 0.2.8 -> 0.2.8 svn -> 0.4 svn -> 0.4 bzr (corrupt) -> 0.4 bzr (fixed) -> 0.4 (what we work with). No, I don't like it either. Or, of course, we could try importing both 0.2.8 bzr and fixed 0.4 bzr into git and then use the two-way git sync to merge.