GroundControl2MT Posted October 26, 2010 Share Posted October 26, 2010 I'm a big fan of fallout and just got the pc version recently so bare with me if this sounds dumb I've seen Garrysmod use a program called SVN, you can mark a folder that has files in it and it will make sure their always up to date with whatever files the developer puts on some sever thing, right about here it goes over my head but basically it keeps files up to date with little effort from the end user, hopefully you get the idea. so whats stopping the fallout community from using it. here is one of the more common clients used to keep files up to date, its called Tortise SVN Link to comment Share on other sites More sharing options...
njr Posted October 27, 2010 Share Posted October 27, 2010 Subversion is a form of version control, I don't see why not. In fact it sounds like a good idea if you need to backtrack into previous builds. Link to comment Share on other sites More sharing options...
WuphonsReach Posted October 28, 2010 Share Posted October 28, 2010 While you can use SVN that way... it probably isn't that efficient. There's some hope (and talk) that the next version of FOMM (or one of the other mod managers) will add some logic to check the Nexus to see if there are new release files. Not sure which mod managers are considering it or if it will ever happen. A dedicated tool that watches something like the Nexus will work better in the long run. That being said... I'm a very strong proponent of using version control systems (VCS) if you're making mods. Personally, I use SVN, but you could use Git, or Mercurial, or CVS, or (shudder) RCS, or some proprietary commercial package. The important concepts to know are (these are SVN's terms): - "Working copy" is the directory where you are actually making the edits (i.e. steamapps / common / fallout new vegas / data). It keeps track of what has changed, when the last update was, and what path/URL is used to talk to the repository or server. - "Repository" is the server-specific location where all revisions and meta-data gets stored. Depending on the VCS, this might be a local directory on another local drive, or an application that runs on a server somewhere. - "Check out" is only ever used once and is how you create a working copy and associate it with a server repository. Typically, you have to do the initial checkout into an empty folder. - "Commit" or "Check-In" is the action that you perform which sends whatever is currently in your working copy up to the repository. - "Update" is the process of bringing down latest changes from the repository to your working copy. - "Export" is the process of bringing down data from the repository, without creating a working copy. Useful for exporting files without creating SVN's hidden control folders. - "Revert" allows you to roll a file back to a previous commit. - "Revision History" is a way to look back at all previous commits. Sometimes referred to as the "log" or "change log" or "commit log". Different VCS systems do things in slightly different ways, but the basic concepts are all pretty much identical. ... That's the hard part. Here's briefly what my work flow ends up looking like: 1) I have a central working copy for all of my mods, at D:\ WuphonsReach \ Fallout3 \ ProjectsNV \, under there I have 1 folder per mod. Each mod's project folder has multiple sub folders, but the important folder for me is called "Src". This is where I keep my master ESP for that mod. (My repository is stored on a Linux server, which is an entirely different machine.) 2) I fire up GECK, pick the ESMs and set my ESP to the active ESP. Do some work/changes. Save the ESP. 3) Copy the changed ESP out of "steamapps / common / fallout new vegas / data" and into my "Src" folder. (Which works better then trying to make the data folder a working copy.) I have a batch file named after my ESP file. So for my RandomizedSnowGlobes.esp, I have a batch file named "RandomizedSnowGlobes.cmd". In that batch file, it does: copy /y RandomizedSnowGlobes.esp D:\WuphonsReach\Fallout3\ProjectsNV\RandomizedSnowglobesNV\Src\pause That lets me either copy the ESP manually with copy/paste, or simply run a batch file to do the copy. 4) I now [Alt-Tab] to my working copy (D:\ WuphonsReach \ Fallout3 \ ProjectsNV \ RandomizedSnowglobesNV \ Src \). I then right-click "commit" with TortoiseSVN and enter a change comment like "added a 10th spawn point for the Goodsprings Globe". That way I know what changed in this revision in case I have to roll-back (or "revert") later. It probably sounds complicated until you do it a few times. Change file, copy to the working copy, commit. Rinse, repeat, ad nauseum. But it saves my bacon numerous times when GECK decides to do something really stupid - or I have a stupid moment in GECK - because I can always go back to a previous version and with the log messages I won't have to guess. Plus I can glance at the change log for that particular file, look at the commit messages, and quickly write up a change log for the ReadMe file. My project folder structure current looks like: ProjectName\- Src (the ESP and ReadMe file)- FOMOD (the XML file for a FOMOD version)- Textures- Images- Design- Releases (with sub-folders like "1.00")- Scripts (I copy all scripts out to text files, which makes it easier to do "diffs" across changes)- Messages (same, I copy all message strings out to text files as a record) But really, as long as you are backing up your work regularly and can roll back to any point in time, and it's an easy enough task that you don't put it off, any method works well. I just tend to be a bit paranoid about protecting myself from my own stupidity so I make frequent commits. Link to comment Share on other sites More sharing options...
Recommended Posts