Collectible Card Game Headquarters

Tentative target release date: Friday August 29 2014.

I just finished introducing Auto-Yield support for abilities on the stack to the desktop game. You can now tap on abilities on the stack and check "Auto-Yield" to avoid needing to press OK to resolve them for the rest of the game. If you want to temporarily disable them or remove them, you can select a new Auto-Yields item under the Game menu to open a dialog with a checkbox to disable all auto-yields or remove any active yields you choose.

I'm not really sure where this would fit, as this is more of a "what-if" than anything else...

Since there's been interest in migrating to Git in the past, is there still any interest in doing so? It's been mentioned several times that at least one previous attempt to do so was not successful, but I may be able to get it to work now. I've been doing a lot of migration from Subversion to Git at work and have the process down pretty well now.

This is just a hypothetical question for the most part and since Subversion has worked (and continues to do so) for us, switching may not be entirely beneficial. If there is, however, enough interest, I could give it a shot and see what everyone thinks without having to officially move away from Subversion.

The failure wasn't due to code migration, it was due to some of the active developers (including all of the people who aren't developers but who are involved in script testing/creation) being unable to work in a Git environment. Are there any proposed benefits that are different than the benefits mentioned at that time? At the time we basically just lost 2 weeks, due to switching over, and than needing to switch back.

Maybe we can do a quick head count to see who has any Git experience? For me, it'd be totally fine (better than svn, even), and if everyone feels that way, then I'd certainly consider moving. But if there's people without Git experience, it's what you say; it'd probably cost more time and resources than it would ever save us.

friarsol wrote:The failure wasn't due to code migration, it was due to some of the active developers (including all of the people who aren't developers but who are involved in script testing/creation) being unable to work in a Git environment. Are there any proposed benefits that are different than the benefits mentioned at that time? At the time we basically just lost 2 weeks, due to switching over, and than needing to switch back.

There's a few benefits to Git that Subversion lacks (which sets it ahead, IMO). The first is that everyone has a copy of the entire repository when they clone. Subversion doesn't offer this, so if for some reason the server goes down, previous commit data could be lost (I'm not sure on the specifics there).

Git also uses pointers for branches instead of full-on copies, which makes switching, creating, and destroying branches super fast. It also means that the repo remains really small even with a lot of branches/tags/etc.

Git is much more popular than Subversion, so we may find a few more people to help develop things.

Finally, I just plain like working with Git more than Subversion. I can work with both, but sometimes Subversion gives me headaches for things that should be easy to accomplish. This is somewhat of a personal choice, but I also see more newcomers preferring Git over Subversion for that reason.

Really, the biggest benefits here would be easy branching and merging so large features could be developed while keeping up-to-date on their own branches.

It may be a good idea to see who here feels strongly one way or another as elcnesh has said. There's always the point that "if it ain't broke, don't fix it" that certainly applies here, too, so I'd only actually look into testing out a migration if people really want to. Should I start up a poll for this?

I prefer Subversion personally, as I use it at work and I like how simple TortoiseSVN makes everything. Given that I probably do more commits these days than just about anyone else, unless there's a strong opposition to SVN from everyone else, I'd request we not change anything.

Are we really running into issues that Subversion isn't good enough?

drdev wrote:Are we really running into issues that Subversion isn't good enough?

No, but it's been brought up a few times by a few different people, so I thought I'd see what everyone really thought about it.

Honestly, I don't think the Git is more popular is benefit that really matters, and using Git could possibly turn off developers who can't figure out how to use it, whereas someone used to Git can figure out SVN in about 3 seconds. This is a very real problem that people who prefer Git seem to brush under the water, and it has happened in Forge's past with an annoying and time costly manner.

There have been plenty of features developed on branches within Forge in the past, and there's no reason why people can't do it in the future. svn copy is pretty fast, and it creates cheap copies, so it seems that's a bit overstated in your argument.

SVN Copies | Open

Cheap Copies

Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects.

This is why you'll often hear Subversion users talk about “cheap copies.” It doesn't matter how large the directory is—it takes a very tiny, constant amount of time and space to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a “cheap copy” of the previous revision, with a few items lazily changed within. (To read more about this, visit Subversion's web site and read about the “bubble up” method in Subversion's design documents.)

Of course, these internal mechanics of copying and sharing data are hidden from the user, who simply sees copies of trees. The main point here is that copies are cheap, both in time and in space. If you create a branch entirely within the repository (by running svn copy URL1 URL2), it's a quick, constant-time operation. Make branches as often as you want.

I strongly think we shouldn't be flipping over to Git. Of all things that Forge has been hindered by, I've never thought it's the version control.

I would likely stop releasing the betas and snapshots if we went back to git as it was more complicated for me ... and for other people too.

Initially, the original dev Rares had to cease due to the C&Ds that he received after applying for a job at wotc as he was using his forge project in his attempt to get a job.

Dennis took over and set up a googlecode address for us while Rares had his own googlecode address for his old blog and he would have our beta archives accessible from his own googlecode address. His address received a C&D and it was shut down. Our own googlecode address never received a C&D.

https://code.google.com/p/cardforge/source/list

I suspect that some panicked when Rares received his last C&D. As a result some insisted that we move to git. Git did not turnout to be a good choice due to various circumstances and we set up a SVN at our present site.

Seems it's decided, then.

Personally I've always liked the "don't fix it unless it's broken" approach, so I think we best stick to svn for the time being, which is the max comfort zone for everyone i think, but if we switch to git some day I won't mind - actually, will be a good chance to learn more about git

- Agetian

i have completed the Innistrad quest world, and made sure all the duel decks and challenges do not contain any "AI can't handle well" cards :
viewtopic.php?f=48&t=9457&p=158705#p158705

So if the devs think it's ok, i would like to propose it to be included in the incoming Forge release

Today's build and deploy attempt ended in a BUILD FAILURE. Looks like another one of those FTP errors while accessing cardforge.org. At least the archives appear to have been built before this error.
 

Code: Select all

[INFO] Command sent: PASV
[INFO]
[INFO] Reply received: 227 Entering Passive Mode (174,34,254,123,71,4)
[INFO]
[INFO] Command sent: STOR TriggerReplacementBase.html
[INFO]
[INFO] ftp://ftp.cardforge.org/site/ - Session: Disconnecting 
[INFO] ftp://ftp.cardforge.org/site/ - Session: Disconnected
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] Forge Parent ...................................... SUCCESS [3:11.774s]
[INFO] [INFO] Forge Core ........................................ SUCCESS [2:38.322s]
[INFO] [INFO] Forge Game ........................................ FAILURE [8:37.488s]
[INFO] [INFO] Forge AI .......................................... SKIPPED
[INFO] [INFO] Forge Net ......................................... SKIPPED
[INFO] [INFO] Forge Gui ......................................... SKIPPED
[INFO] [INFO] Forge ............................................. SKIPPED
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 14:28.753s
[INFO] [INFO] Finished at: Fri Aug 29 11:00:33 EDT 2014
[INFO] [INFO] Final Memory: 64M/514M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:deploy (default-deploy) on project forge-game: Error uploading site: IOException caught while attempting to upload /Users/me/Workspace_SVN/ForgeSVN/target/checkout/forge-game/target/site/xref/forge/game/TriggerReplacementBase.html: Read timed out -> [Help 1]
[INFO] [ERROR]
[INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
[INFO] [ERROR]
[INFO] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[INFO] [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[INFO] [ERROR]
[INFO] [ERROR] After correcting the problems, you can resume the build with the command
[INFO] [ERROR]   mvn <goals> -rf :forge-game
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Forge Parent ...................................... FAILURE [19:17.028s]
[INFO] Forge Core ........................................ SUCCESS [1:38.781s]
[INFO] Forge Game ........................................ SUCCESS [4:02.106s]
[INFO] Forge AI .......................................... SUCCESS [2:00.108s]
[INFO] Forge Net ......................................... SUCCESS [27.760s]
[INFO] Forge Gui ......................................... SUCCESS [2:17.803s]
[INFO] Forge ............................................. SUCCESS [7:37.727s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 39:18.513s
[INFO] Finished at: Fri Aug 29 11:00:33 EDT 2014
[INFO] Final Memory: 60M/579M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5:perform (default-cli) on project forge: Maven execution failed, exit code: '1' -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
logout