Sourceforge downtime -- discussion of alternatives
- Thread starter heeheehee
- Start date
Morgoth1145
Member
I would recommend Git Extensions to anybody who has not tried it. I would recommend Git Extensions over TortoiseGit (which I saw mentioned in this thread as well.) Its installer bundles msysgit so that you don't need to go searching for git itself, and it provides GUI hooks for most anything you would likely need. There are reasons to drop down to the command line sometimes, but it shouldn't be necessary until you're more comfortable with git.
To anybody who only has used SVN, honestly, you're going to need to forget some things that you learned from SVN. Distributed version control systems have some fundamental differences with centralized version control systems. If you try to think in terms of SVN, you're only going to end up confused. And once you learn git, you'll likely find that it wasn't really that complicated all along. It was just different than what you knew.
When we converted to git at work somebody found this tutorial. It may be helpful to some: http://pcottle.github.io/learnGitBranching/. Please note that it is command line based. Please also note that there *are* some differences with the actual git command line. However, the key is getting you to understand how distributed version control systems work, and for that it should be helpful. Note that github and other places also have git tutorials, but learnGitBranching is the only one I've seen that also shows a representation of the local repository commit graph.
Now all that being said, I would (as somebody who does not contribute at all to KoLMafia or any ash scripts) that you guys convert to git. In my opinion, the only advantage that SVN has over git is inertia.
To anybody who only has used SVN, honestly, you're going to need to forget some things that you learned from SVN. Distributed version control systems have some fundamental differences with centralized version control systems. If you try to think in terms of SVN, you're only going to end up confused. And once you learn git, you'll likely find that it wasn't really that complicated all along. It was just different than what you knew.
When we converted to git at work somebody found this tutorial. It may be helpful to some: http://pcottle.github.io/learnGitBranching/. Please note that it is command line based. Please also note that there *are* some differences with the actual git command line. However, the key is getting you to understand how distributed version control systems work, and for that it should be helpful. Note that github and other places also have git tutorials, but learnGitBranching is the only one I've seen that also shows a representation of the local repository commit graph.
Now all that being said, I would (as somebody who does not contribute at all to KoLMafia or any ash scripts) that you guys convert to git. In my opinion, the only advantage that SVN has over git is inertia.
If you don't bother to use branches (it seems easy enough to pretend they don't exist for this project at least), then what advantage does git have?
Off the top of my head,
1) the ability to commit multiple things without synchronizing with a central repository
2) a much larger and more powerful selection of commands (off the top of my head, git cherry-pick, git bisect, and git stash are fairly useful ones that svn lacks; the ability to define your own commands via git alias also helps)
3) less awkward conventions for setting ignored files and configuration details, both locally (for a specific repo) and globally (on a specific machine).
1) the ability to commit multiple things without synchronizing with a central repository
2) a much larger and more powerful selection of commands (off the top of my head, git cherry-pick, git bisect, and git stash are fairly useful ones that svn lacks; the ability to define your own commands via git alias also helps)
3) less awkward conventions for setting ignored files and configuration details, both locally (for a specific repo) and globally (on a specific machine).
The best advantage of git (or another DVCS) is that it is much more fault-tolerant than centralized version control.
A local version of a repository (what you get from a "git clone", the equivalent of an "svn checkout") is the entire repository. All history, all artifacts, everything. This means that if your central repository takes a dive, everyone who has an up to date clone has a full backup.
Since clones are fully fledged repositories, it also means that you can push code changes from your local repo to someone else's local repo (provide you have network access of course) while you wait for the central repo to come back up. Once the central repo is back up, those changes are pushed to the central repo and everything continues as if nothing happened.
As an example, let's pretend that we were using git on sourceforge rather than SVN. (Also I apologize for picking names and details out of a hat, this is just an illustration)
1) Sourceforge goes down
2) Rather than waiting a week for sourceforge to come back up, Fewyn sets up a new temporary git repo on the kolmafia.us servers. (If Fewyn doesn't have a clone handy, any dev with a clone can basically give Fewyn a fresh clone)
3) matt.chugg updates the build process to point to the temporary repo rather than the sourceforge location.
4) Veracity commits changes for more deck of every card functionality and pushes them to the temporary repo.
5) Lostcalpolydude pulls the changes down from the temp repo, commits the fixes for inline item descriptions, pushes them to the temp repo.
6) Other devs push their own changes to the temp repo.
7) The build process picks these changes up and churns out jars as if nothing is wrong.
8) Sourceforge comes back online
9) Fewyn (or any of the devs with an up to date local repo) push the missing changes to the sourceforge repo
10) matt.chugg updates the build process to point back to the sourceforge repo.
11) The build process picks up changes and makes jars as usual.
Git (or any other DVCS) are built for this kind of thing. They are built to handle any necessary merging in case dev A tries to push to the repo without dev B's code. Their automatic merging is light years ahead of an SVN merge.
To throw my own two cents in (as someone with a professional source code management background but not a script or kolomafia dev and thus little skin in the game) mercurial (hg) is much easier to transition to from an svn background. The git command line has a lot of power but has piles of command line flags and arguments that are really confusing for someone starting out. Mercurial's command line is much closer to SVN's command line and TortoiseHg will be familiar to anyone used to TortoiseSVN. (For some reason, TortoiseGit is not nearly as well developed as TortoiseHg and TortoiseSVN). With that said, mercurial does not have anywhere near the adoption that git does, so online resources for git repo hosting and commands and whatnot are much more prevalent than the mercurial equivalent. Either git or mercurial will be better than SVN, even if no fancy branching is used.
http://hginit.com/00.html is an excellent SVN to mercurial overview written by Joel Spolsky of the Joel on Software/Stack Overflow/FogCreek fame. It is worth reading even if we move to git, as the principles are the same even if the specific command are different.
tl;dr:
The best advantage of git (or any DVCS) over SVN is that it can easily adapt to the loss of a central repository and continue functioning. With SVN, you are dead in the water when the central repo is down. Anyone using git has a fully functional copy of the central repo, which can be turned into a new central repo
So it would have been easier to ditch sourceforge for github (fewyn already has a local svn repository to compile builds to make available here). If we were going to interact at all with a repo hosted here, I think the work for fewyn setting it up properly would mean that it's a permanent process.
I'm kind of curious what it's like to handle multiple branches in an IDE (I currently use NetBeans), with the contents of multiple already-open files changing.
I'm kind of curious what it's like to handle multiple branches in an IDE (I currently use NetBeans), with the contents of multiple already-open files changing.
Code:
$ svn update
Updating '.':
svn statusAt revision 16065.
Code:
$ svn commit
Sending src/data/coinmasters.txt
Sending src/data/defaults.txt
Sending src/data/fullness.txt
Sending src/data/inebriety.txt
Sending src/data/items.txt
Sending src/data/modifiers.txt
Sending src/data/monsters.txt
Sending src/data/spleenhit.txt
Sending src/data/statuseffects.txt
Sending src/net/sourceforge/kolmafia/RequestEditorKit.java
Sending src/net/sourceforge/kolmafia/persistence/CoinmastersDatabase.java
Sending src/net/sourceforge/kolmafia/persistence/ConsumablesDatabase.java
Sending src/net/sourceforge/kolmafia/persistence/DebugDatabase.java
Sending src/net/sourceforge/kolmafia/persistence/ItemDatabase.java
Sending src/net/sourceforge/kolmafia/persistence/ItemFinder.java
Sending src/net/sourceforge/kolmafia/request/DeckOfEveryCardRequest.java
Sending src/net/sourceforge/kolmafia/request/EquipmentRequest.java
Sending src/net/sourceforge/kolmafia/request/MrStoreRequest.java
Sending src/net/sourceforge/kolmafia/request/StorageRequest.java
Sending src/net/sourceforge/kolmafia/request/SwaggerShopRequest.java
Sending src/net/sourceforge/kolmafia/request/UseItemRequest.java
Sending src/net/sourceforge/kolmafia/session/EventManager.java
Sending src/net/sourceforge/kolmafia/session/InventoryManager.java
Sending src/net/sourceforge/kolmafia/session/QuestManager.java
Sending src/net/sourceforge/kolmafia/swingui/CoinmastersFrame.java
Sending src/net/sourceforge/kolmafia/textui/command/TestCommand.java
Transmitting file data ..........................
svn: E200014: Commit failed (details follow):
svn: E200014: Base checksum mismatch on '/src/net/sourceforge/kolmafia/request/EquipmentRequest.java':
expected: 5671869ea0e1d770008922d0d778459e
actual: c6f6170b2b2093309db522a14c148117
svn: E200014: Your commit message was left in a temporary file:
svn: E200014: '/src/kolmafia/svn-commit.2.tmp'Looks like we lost a couple of commits.
I see that lost committed 16064 and 16065 a few hours ago.
The problem is, we already had revisions 16064 and 16065. From the Latest SVN changes folder:
and
Now, my commit 16066 had DeckOfEveryCardRequest.java and UseItemRequest.java in it, so it incorporated those changes, but the changes I made to ManaBurnManager.java are gone.
I'll resubmit them.
Code:
------------------------------------------------------------------------
r16066 | veracity0 | 2015-07-25 20:08:34 -0400 (Sat, 25 Jul 2015) | 33 lines
Fix 11 monster ids, as reported by Manuel, thanks to ckb.
Add four (obsolete) monsters that have returned from the dead via the DoEC.
Change checkitems to check quality and size of consumables as well as
whether an item is a Fancy cooking or cocktailcrafting ingredient.
Fix several items that are fancy ingredients but were not so-marked
Add new foods resulting from the Pastapocalypse and fix size, quality,
and level requirement of existing foods that changed.
Detect when a new item is a fancy ingredient and mark it as such.
When we generate the consumables line while registering a new
consumable, the note is "Unspaded"
Add a new status effect and fix effect granted by antique bottle of cough syrup.
Unidentified items in storage cannot be discovered via api.php
When you tell KoLmafia to pull N of an item, pull exactly N, not all available
Look for "Desert exploration" to decide if you've successfully explored, rather
than assuming every fight in the desert counts; clingy follow-on fights don't.
lost's regexp changes to keep native inline item descriptions from screwing up
our model of equipment
Handle variable priced conditional Swagger Shop items
Handle alternative event format from main.php and only process old-style events
for now - ones that have a time stamp and are not in an HTML table
------------------------------------------------------------------------
r16065 | lostcalpolydude | 2015-07-25 18:51:38 -0400 (Sat, 25 Jul 2015) | 1 line
Handle native inline description popups
------------------------------------------------------------------------
r16064 | lostcalpolydude | 2015-07-25 18:49:27 -0400 (Sat, 25 Jul 2015) | 1 line
Fix some monster ids, a few modifiers, and add talking spade
------------------------------------------------------------------------
r16063 | lostcalpolydude | 2015-07-14 22:15:25 -0400 (Tue, 14 Jul 2015) | 1 line
Since KoL now auto-pulls the VIP key, remove the code for handling thatThe problem is, we already had revisions 16064 and 16065. From the Latest SVN changes folder:
Code:
16064: If using the Deck of Every Card is known to lead to a fight (we are "cheating"
If using the Deck of Every Card is known to lead to a fight (we are "cheating" a
monster) or might lead to a fight (we are doing a random draw), run between
battle checks before submiting the request, to allow recovery scripts to run.
by veracity0 on 2015-07-15 17:52:54
M /src/net/sourceforge/kolmafia/moods/ManaBurnManager.java (view) (diff)
M /src/net/sourceforge/kolmafia/request/DeckOfEveryCardRequest.java (view) (diff)
M /src/net/sourceforge/kolmafia/request/UseItemRequest.java (view) (diff)
Code:
16065: Provide equals() method for EveryCard and use a HashSet rather than a TreeSet
Provide equals() method for EveryCard and use a HashSet rather than a TreeSet
by veracity0 on 2015-07-15 18:39:36
M /src/net/sourceforge/kolmafia/request/DeckOfEveryCardRequest.java (view) (diff)I'll resubmit them.
OK, it looks like ManaBurnManager.java in the repository really does have the changes.
I bet lost's commits explain the checksum errors I got with EquipmentRequest: he submitted revisions 16064 and 16065 (which included EquipmentRequest), but I already had the original version of those revisions, and EquipmentRequest had a different checksum.
I bet lost's commits explain the checksum errors I got with EquipmentRequest: he submitted revisions 16064 and 16065 (which included EquipmentRequest), but I already had the original version of those revisions, and EquipmentRequest had a different checksum.
txrangersxx
Member
I have a couple issues to submit but I want to write them up well. Just FYI, one has to do with an recognized choice adventure(382), the other is buying multiple copies of can of black paint even though you have it, and going after 2 gaudy keys if you already have one key and end automation and restart it doesn't recognize that 1 is already gotten. I will try to write up with logs tomorrow.
No, try reading more of that thread where it came up in the first place.
txrangersxx
Member
Ok checked that one off the list
I see no reason that we have to abandon the svn library inside KoLmafia and force users to switch. Why not have SVNkit (as now) AND something like jgit? Presumably we'd have a per-script flag that said whether it was SVN or GIT - and perhaps the command to update all of your installed scripts shouldn't be "svn update". It would be a Project.
Maybe. Or maybe not. A little googling led me to svn2git which is supposedly a painless way to import an SVN project - including all of the history; each separate commit is individually inserted into the git project, as I understand it. So, it doesn't sound like the conversion will be "painful". Just the learning curve for git, for those of us who have never used it before. But, yes - we all need to be on board before attempting it.
Sure would have been nice, given the 10-day wait we just suffered through.
I haven't used netbeans in particular, but they seem to integrate with git. The IDEs that I have used have a "version control" menu where the commands for dealing with git live. There are usually wizards or pop up menus that handle switching branches. With that said, git can handle a "trunk only" dev style just fine, so you mainly just commit your stuff, pull changes from the central repo, automatically merge them into your working copy (some IDEs will pop up a "file has changed, do you want to refresh?" box, others will just update the contents if you have the files opened), then commit any merges and push to the central repo.
Another situation where git shines is the recent fun between Lostcalpolydude and Veracity committing at around the same time. The way git handles it is by automatically creating a mini-branch, one where Veracity's changes are there and one where Lostcalpolydude's changes are there. One person then resolves it by merging one branch into the other and committing and pushing that merge. Code history stays intact. If you later realize that the merge was done incorrectly, you have both originals to go back to when you re-merge. And again, merging in git is MUCH less painful than SVN merging. That's not to say that these types of things can't be resolved in SVN, it's just much less labor intensive IMO because git takes care of a lot of the work.
Anyway, I'm glad sourceforge is back up. You all are very generous to spend your time keeping kolmafia going, so thanks for all the awesome you do.
On one hand, I don't know how I feel about including yet another SCM library in Mafia, because the problem then becomes where we draw the line. Do we include a Mercurial library? How about Darcs? Or Bazaar? Hell, there's even a version control system called Veracity.
On the other hand, it could be an interesting project, but it'd probably take some significant effort to implement fully.
For what it's worth, I'm currently using git-svn, which allows me to fetch SVN updates into a local git repository and even make commits from there. In fact, this is how hola mirrored Mafia's source code to github, apparently. This... could be a decent way to grasp the learning curve before committing to migrating, I guess.
Actually, as far as I can tell, the recent fun actually involved Sourceforge losing a few commits from shortly before the outage; Lost's commits got added to the centralized repository as the new "ground truth" for r16064-5 or whatever, which led to all sorts of checksum issues.
Ended up having to delete the directory and re-checkout, but took a snapshot of changes I'd made and not committed first.
Now am getting authorisation failed when I try to commit. I using "svn://svn.code.sf.net/p/kolmafia/code/" from http://wiki.kolmafia.us/index.php?title=Compiling_from_Source, but have a sneaking memory that I need to use something else to commit. My saved connection details work to sourceforge ok.
What have I done wrong? Or is it just not all working yet?
Edit - I needed https:// rather than svn://
Now am getting authorisation failed when I try to commit. I using "svn://svn.code.sf.net/p/kolmafia/code/" from http://wiki.kolmafia.us/index.php?title=Compiling_from_Source, but have a sneaking memory that I need to use something else to commit. My saved connection details work to sourceforge ok.
What have I done wrong? Or is it just not all working yet?
Edit - I needed https:// rather than svn://
Last edited: