Related
There are a few mercurial extensions for dealing with large binary files.
Bfiles
BigFiles
Snap
kbfiles
others?
I'd like to use the one that is most likely to be official (ie distributed with mercurial).
Kiln 2.0 uses a fork of Bfiles for its binary files. Does that make it more likely to become official?
Which is the preferred (semi-official) extension for handling binary files?
It appears that Mercurial is planning to incorporate the 'largefiles' extension for the November 2.0 release. Mercurial incorporated the 'largefiles' extension in the 2.0 release. This extension is a descendent of 'kbfiles' (from Kiln), which is in turn a descendent of the bfiles extension.
It makes largefile support much more integrated into the Mercurial commands than bfiles did, and supports pushing to http(s) urls which I believe bfiles did not.
Kiln repo
preparation work on mercurial-devel
release expectations
It's too early to tell. And it is way too early to start talking about including any of these extensions with Mercurial. IMHO they should all be considered experimental.
(I'm the author of one of those extensions (bfiles), so this is as authoritative an answer as you are likely to get. If someone proposed shipping any one of these extensions with Mercurial today, including mine, I would be strenuously opposed.)
Also, there is no logical link between game development and which extension to choose. It doesn't matter if you're tracking movies, game data, jar files, medical imaging data, or what: most source-control systems are not very good at handling it, and there is no clear answer yet which is the right way to do it with Mercurial.
IMHO stackoverflow is really not the right place for this sort of discussion; the mercurial-devel list is.
It seems that BigFiles is recommanded by game developpers using Mercurial, so maybe you should go with it. However if you want to know wich one is worked to be included in a coming version of mercurial, you should ask in or read the developers' mailing list.
Errr... Nexus. Or any other artifact repositories (or any other backup systems if you only need the latest version).
Because no binary file (especially large one) really belong to a VCS where you would want to diff or merge.
Sure, you could use a VCS, and there are actually good arguments for it, but a VCS is simply not designed for that at its core.
I work on a large project where all the source files are stored in a version control except the project files. This was the lead developer's decision. His reasoning was:
Its to time consuming to reconcile the differences among developers' working directories.
It allows developers to work independently until their changes are stable
Instead, a developer initially gets a copy of a fellow developer's project files. Then when new files are added each developer notifies all the rest about the change. This strikes me as far more time consuming in the long run.
In my opinion the supposed benefits of not tracking changes to the project files are outweighed by the danger. In addition to references to its needed source files each project file has configuration settings that would be very time consuming and error prone to reproduce if it became corrupted or there was a hardware failure. Some of them have source code embedded in them that would be nearly impossible to recover.
I tried to convince the lead that both of his reasons can be accomplished by:
Agreeing on a standard folder structure
Using relative paths in the project files
Using the version control system more effectively
But so far he's unwilling to heed my suggestions. I checked the svn log and discovered that each major version's history begins with an Add. I have a feeling he doesn't know how to use the branching feature at all.
Am I worrying about nothing or are my concerns valid?
Your concerns are valid. There's no good reason to exclude project files from the repository. They should absolutely be under version control. You'll need to standardize on a directory structure for automated builds as well, so your lead is just postponing the inevitable.
Here are some reasons to check project (*.*proj) files into version control:
Avoid unnecessary build breaks. Relying on individual developers to notify the rest of the team every time the add, remove or rename a source file is not a sustainable practice. There will be mistakes and you will end up with broken builds and your team will waste valuable time trying to determine why the build broke.
Maintain an authoritative source configuration. If there are no project files in the repository, you don't have enough information there to reliably build the solution. Is your team planning to deliver a build from one of your developer's machines? If so, which one? The whole point of having a source control repository is to maintain an authoritative source configuration from which you build and deliver releases.
Simplify management of your projects. Having each team member independently updating their individual copies of your various project files gets more complicated when you introduce project types that not everyone is familiar with. What happens if you need to introduce a WiX project to generate an MSI package or a Database project?
I'd also argue that the two points made in defense of this strategy of not checking in project files are easily refuted. Let's take a look at each:
Its to time consuming to reconcile the differences among developers' working directories.
Source configurations should always be setup with relative paths. If you have hard coded paths in your source configuration (project files, resource files, etc.) then you're doing it wrong. Choosing to ignore the problem is not going to make it go away.
It allows developers to work independently until their changes are stable
No, using version control lets developers work in isolation until their changes are stable. If you each continue to maintain your own separate copies of the project files, as soon as someone checks in a change that references a class in a new source file, you've broken everyone on the team until they stop what they're doing and carefully update their project files. Compare that experience with just "getting latest" from source control.
Generally, a project checked out of SVN should be working, or there should be tools included to make it work (e.g. autogen.sh). If the project file is missing or you need knowledge about which files should be in the project, there is something missing.
Automatically generated files should not be in SVN, as it is pointless to track the changes to these.
Project files with relative path belong under source control.
Files that don't: For example in .Net, I would not put the .suo (user options) web.config (or app.config under source control. You may have developers using different connection strings, etc.
In the case of web.config, I like to put a web.config.example in. That way you copy the file to web.config upon initial checkout and tweak what settings you'd like. If you add something that needs to be added to all web.config, you merge those lines into the .example version and notify the team to merge that into their local version.
I think it depends on the IDE and configuration of the project. Some IDEs have hard-coded absolute paths and that's a real problem with multiple developers working on the same code with different local copies and configurations. Avoid absolute path references to libraries, for example, if you can.
In Eclipse (and Java), it's fine to commit .project and .classpath files (so long as the classpath doesn't have absolute references). However, you may find that using tools like Maven can help having some independence from the IDE and individual settings (in which case you wouldn't need to commit .project, .settings and .classpath in Eclipse since m2eclipse would re-create them for you automatically). This might not apply as well to other languages/environments.
In addition, if I need to reference something really specific to my machine (either configuration or file location), it tend to have my own local branch in Git which I rebase when necessary, committing only the common parts to the remote repository. Git diff/rebase works well: it tends to be able to work out the diffs even if the local changes affect files that have been modified remotely, except when those changes conflict, in which case you get the opportunity to merge the changes manually.
That's just retarded. With a set up like that, I can have a perfectly working project containing files that are subtly different from everyone else. Imagine the havoc this would cause if someone accidentally propagates this mess into QA and everyone is trying to figure out what's going on. Imagine the catastrophe that would ensue if it ever got released to the production environment...!
I've recently taken on a project with no version control. I don't have any experience with version control myself. I feel it is the only way to go with this project (and probably any future projects now I think of it - I always trust myself too much..)
My question is - where do I begin with implementing version control on a project already in production? Bearing in mind I haven't used version control before so really it's two separate questions:
Starting out with version control
Implementing it on an already live
project
For background, the project is a php/mysql driven website using bits of javascript, I'm working on a (Windows) XAMPP server and I'm very keen to learn this new world of version control!
Congratulations, you are headed in the right direction!
You'll first need to choose a version control system. My current favorite is Git. Unfortunately, I don't think that Git is an easy introduction to version control. I have also used Subversion and Perforce.
Subversion (http://subversion.tigris.org/) works on many platforms, is used in a lot of projects, and has some nice GUI tools available (such as TortoiseSVN on Windows). Command-line tools are also available. It's also free. You can run it in "local filesystem" mode, meaning that you don't need to set up a separate server. It's come a long way from it's "better than CVS" roots.
Perforce (http://www.perforce.com/) is pretty nice. Its Windows implementation seems the best (last I checked, their cross-platform GUI was pretty lousy). You primarily use a GUI to interact with it, though again there are command-line tools. It's commercial software, but open source projects can get free licenses by contacting the company. The biggest drag is that you will need to set up a server. To get started, you could run the server on the same box that you develop on, but that's probably a bad idea in the long run. I found Perforce to be very good for 2-8 person teams; I don't know how well it would work with more.
The big advantage to Git (http://git-scm.com/) is that it requires virtually no set-up. Once installed, you can execute git init in any directory to create a new git repository. The revision history is kept inside the project's directory. You can start out with just local versioning, and you can scale up from there. If Git seems scary, you could also check out Mercurial (https://www.mercurial-scm.org/). I haven't used it, but I understand that it shares some of the same underlying principles as Git.
Avoid CVS. It's on its way out, and no new project should be using it unless they need to do so.
Adding source control to an existing project is easy. The hard part would be making sure that everybody is willing to use source control. If you're working alone, then it's just personal discipline. If you're part of a team, though, and some people have reservations, you will have problems. Try to get everybody on board, and be available to try to answer their questions. If people don't know how to use a tool, they simply won't use it.
Start here: http://svnbook.red-bean.com/
I've found SVN to be the easiest version control system to use, especially for beginners. It's pretty simple to start, the only real decision you have to make is where to host your stuff. There are a couple free svn servers available, but if you're really serious about your work you should host your own.
The first thing to do is to pick a version control paradigm (centralized versus distributed). To answer that, you'll need to take a look at your team and how you intend to handle check-in, check-out, merging, and branching. Once you pick a paradigm, you can choose a version control system. The mainstream systems are Subversion for centralized version control and Git and Mercurial for distributed version control.
If the project is live and working, then that should be your initial check-in to whatever version control you are using. You need a reliable baseline that you can revert to and have 0 work to deploy something that works. If your project is not functional...well, good luck. You might want to check in to start using version control and then decide how you want to proceed (either get the project to a stable and functioning state and then restart your repository or have your initial check-in be a broken system).
If the rest of the team doesn't see the benefit with version control, I would recommend installing your own system on your machine and, at the very least, use it for your own work.
Be prepared for some resistance from management and/or your co-workers. Management may not want to invest the resources for a repository machine -- these things need to be installed, maintained, backed-up, etc. Or they may object to you spending time on an "extra" like a RCS.
Your co-workers, especially if they're unfamiliar with any RCS, are likely to resist using it, or complain that it's too hard to use. There's a learning curve to any new tool, and source control systems are no exception. It's worth the time to learn, though.
My advice is to pick one -- any one that strikes your fancy -- and start using it. Don't worry about getting it 100% perfect the 1st time, it probably won't be any worse than what you have now, which is one misplaced keystroke away from oblivion.
Play with it. Check files out into a separate workspace and hack things up, knowing that it doesn't matter; you can always revert it. Learn how to use your new tool with some GUI frontends (I'm fond of 'svn diff --diff-cmd=kdiff3', myself). Get to the point where you know how to check in & out, tags things, branch, and merge. Then show your co-workers.
Personally, I'm fond of svn, but I didn't choose it; it chose me.
Step 1: Download Mercurial.
Step 2: In your favorite command line, go to the root of your source directory and type hg init.
Step 3: Do a make clean or equivalent (ie. all you want is source, no generated files).
Step 4: Type hg addremove.
Step 5: Type hg commit.
From this point on you can:
Examine the changes between your most recent commit and now: hg diff or hg status.
Make checkpoints in your code: hg commit.
Return to previous checkpoints: hg update -C -r 0
Congratulations, you are now using version control: It's really not that hard, and it's very, very useful (if for no other reason than you can look at the changes you've made to see if they make sense).
At some point you'll probably want to learn about branching (if only so that you have a backup copy of your repository on another machine) at which point you can turn to the documentation or the book.
I don't know if there is something similar for php etc, but an interesting resource here is "Brownfield Application Development in .NET". In many ways, this only uses .NET for the examples; most of the book is really about tackling policies exactly like you mention:
how to introduce source control
how to introduce unit testing
how to introduce continuous integration
etc
and all the concerns/consideration that go with them.
Partly relating to the code; but also relating to the "human" factor; colleagues, managers, etc. I highly recommend it; but you might decide the .NET background is inappropriate for you (it is a good fit for me ;-p).
You can look here: git-for-beginners-the-definitive-practical-guide
This one is a distributed version control system that currently has a good windows support with Git on Windows and a shell extension with TortoiseGit
An addition to other answers:
If the project you want to put under version control have had some releases, and if those versions are available for example as tarfiles (e.g. project-0.1.tar.gz, project-0.2.tar.gz, project-0.3.tar.gz, ...) you might want to consider importing those versions into your chosen version control system. Git for example has import-tars.perl and import-zips.py in contrib/fast-import/ directory, and writing support for other files in other programming languages for git fast-import should be easy.
Sidenote: my preferred version control system is Git.
See also: Good link or book for basics and theory of version control question.
I learned the concepts from the pragmatic series:
example for subversion, they also have books on GIT as well.
I only have experience with SourceSafe and SVN.
SourceSafe seems to have issues with corrupting it's own database, on a team of 5 we were repairing the db probably once a month. It's easy, but still something you shouldn't have to deal with. It's difficult to label code too and use that label for anything practical.
SVN is nice, it's simple to install on Linux or Windows. Most IDEs have a plugin for it, and if you're using Windows there is an Explorer extension (TortoiseSVN) that allows you to do all your operations right from Windows Explorer. There's a lot of SVN tools out there for every OS, it's very well supported. SVN also integrates with TRAC (a bug tracking system), and Bugzilla so you can tie your work tickets to code.
I will say that [HOW you use version control is probably just as, if not more important than which package you use][2]. Using it simply as a library is a very rudimentary application of it, but for a 1-2 man team making a website or an app where you won't be maintaining builds and versions, you'll be ok.
When it comes to version control, anything is better than nothing.
Wow, everyone is just boosting his favorite version control utility.
OK, to answer your question, how do you put a project under version control?
It's not that hard, once you pick a version control utility (be it, git, svn, hg, bzr .. whatever) there's usually a command or two to initialize a repository then add all the relevant files to it.
For instance, in git it might be something like:
$git init
$git add --all
$git commit -m"First commit"
Now, about choosing a version control utility, that's a tough question and highly depends on what you want. You might want to have a look at this question:
Popularity of Git/Mercurial/Bazaar vs. which to recommend
The only tools you should consider choosing among are:
git
svn (Subversion)
hg (Merculiar)
bzr (Bazaar)
mtn (Monotone)
Everything else is either old or commercial.
svn follows a server-client model; there's a central repository. If you're a one-man team then the only thing this means to you is that you have to setup a server and make sure it starts with the computer. Though I heard that you can do away with the server. A bit of googling turns up this guide for using svn without a server
All other tools follow a distributed model, again, if you're a one-man team, the only thing this means to you is that there's no server to setup.
The advantage of svn is that it's been there for a while and has many gui front-ends and better IDE integration.
I can't compare git to hg (merculiar) since I haven't used the latter, but git has a unique storage model compared to svn and hg.
bzr is said to be easier to use, but slower (it's written in python).
I'm personally satisfied with git, but you should do your own research; or maybe just choose one and stick with it. As far as I can tell, they're all mature and stable.
I have a project under version control, but the project has some images, videos and zip files that change every so often. I don't want to store these files under version control because they take up a lot of space and make updates and commits very slow.
What's a good way of dealing with this issue and still commit non-source files that have changed? is there a better way?
I'm currently using subversion, if there is another version control client that is better for dealing with this issue, please recommend it!
I have lots of non-source files in SVN and the only time it slows down the commit is when I change them. I don't see how this is an issue if they're only changing "every so often". Also the size really shouldn't be a concern. If your repository is on a server and you're worried about how much space it's taking up you need to upgrade. Hard drives are cheap. Buy them.
Some people feel strongly that non-source files don't belong in source control, I say an entire project should be stored in source control. That way if my development system goes down I can switch to another and after a couple minutes of downloading the project I'm back to coding.
You added in a comment:
The problem I have with this is that I don't care about the version history of those zip/video files, as long as they're the newest ones, there is no problem.
That means you have a linear workflow of development, only working on the LATEST of one main branch.
You do not seem to deal with the phase "after release", where you have to:
maintain what runs in production
develop small evolutions...
..while doing massive refactoring for experimenting some big evolutions
In the last three cases, the question of "what were the exact images, videos and zip files "I have to use" or "I was using at the time" might become important.
Anyhow, if you feel SVN do not handle them appropriately, I would still recommend having some way to remember that, for SVN revision xxx to yyy, you were using the version 'z' of your set of binaries.
For that, you could setup an external repository like Maven. See question "Is it acceptable/good to store binaries in SVN?" (my answer in that question is near the top of the page, but I link directly to Evan's answer as he mentions Maven).
While I find it a huge pain to deal with non-text files in version control, especially ones that change a lot, I've accepted the practice of "if it is needed for the build/installer it should go in version control". This of course is not a hard rule. I don't keep 3rd party libraries under version control (though know people who do).
I came under this opinion after setting up a Continuous Integration server at my shop. Having everything needed for the build that may change make's it much easier. As previously mentioned I don't keep libs under version control, but that is due to the fact that we rarely upgrade/add new libraries. If this is not the case for your shop then you may consider doing so. Also, if your images/videos/zips change more then once a year then I'd recommend keeping them under version control.
We have 2 kinds of people at my shop:
The ones that starts to check-in the code since the first successful compilation.
The others that only checks-in the code when the project is almost done.
I am part of group 1, and trying to convince people of group 2 to act like me. Their arguments are like the following:
I'm the solo developer of this project.
It's just a prototype, maybe I'll have to rewrite from scratch again.
I don't want to pollute the Source Control with incomplete versions.
If I am right, please help me to raise arguments to convince them. If you agree with them tell me why.
When someone asked for good excuses not to use version control, they got 75 answers and 45 upvotes.
And when they asked Why should my team adopt source control, they got 26 answers.
Maybe you'll find something helpful there.
You don't need "arguments to convince them." Discourse is not a game, and you should not use your work as a debating platform. That's what your spouse is for :) Seriously, though, you need to explain why you care how other devs work on solo projects in which other people are not involved. What are you missing because they don't use source control? Do you need to see their early ideas to understand their later code? If you can sucessfully do that, you may be able to convince them.
I personally use version control at all times, but only because I don't walk a tightrope without a net. Other people have more courage, less time to spend on infrastructure, etc. Note that in 2009, in my opinion, hard disks rarely fail and rewritten code is often better than the code that it replaces.
While I'm answering a question with a question, let me ask another one: does your code need to compile/work/not-break-the-build to be checked in? I like my branches to get good and broken, then fixed, working, debugged, etc. At the same time, I like other devs to use source control however they want. Branches were invented for just that reason: so that people who can't get along do not have to cohabitate.
Here's my view to your points.
1) Even solo developers need somewhere to keep their code when their PC fails. What happens if they accidentally delete a file without source control?
2/3) Prototypes belong in source control so other team members can look at the code. We put our prototype code in a seperate location to the mainline branch. We call it Spike. Here's a great article on why you should keep Spike code- http://odetocode.com/Blogs/scott/archive/2008/11/17/12344.aspx
If I'm the sole developer on a project (in other words, the repository, or part of it, is under my complete control), then I start committing source code as soon as it's written, and I tend to check in after every incremental change, whether or not it works or represents any kind of milestone.
If I'm working in a repository on a project with others, then I tend to try and make my commits such that they don't break the mainline development, pass any tests, etc.
Whether or not it's a prototype, it deserves to go into source control; prototypes represent a lot of work, and lessons learned from them are valuable. Plus, prototypes have an awful habit of becoming production code, which you'll want in source control.
I try to only write code that compiles (everything else is commented out with a TODO/FIXME tag)... and also add everything to source control.
Argument 1: Even as a single dev it's nice to roll back to a running version, to track your progress, etc.
Argument 2: Who cares if it's just a prototype? You might stumble upon a similar problem in six months or so, and then just start looking for this other code...
Argument 3: Why not use more than one repo? I like to file misc stuff to my personal repo.
Start using source control about 20 minutes before you write your first line of your first artifact. There is never a good time to start after you're begun writing things.
some people can only learn from experience.
like a hard drive failure. or coding yourself into a dead-end after deleting code that actually worked
now, i'm not saying that you should erase their hard drive and then taunt them with "if only you had used source control"...but if something like were to happen, hopefully there would be a backup done first ;-)
Early and Often. As the Pragmatic Programmers say, source control is like a time machine, and you never know when you'll want to go back.
I would say to them...
I'm the solo developer of this project.
And when you leave or hand it off we'll have 0 developers. All the more reason to use source control.
The code belongs to the company not you and the company would like some accountability. Checking in code doesn't require too much effort:
svn ci <files> -m " implement ajax support for grid control
Next time someone new wants to make some changes on the grid control or do something related, they will have a great starting point. All projects start off with one or two people. Source control is easier now than it ever was--have they arranged a 30 minute demo of Tortoise SVN with them?
It's just a prototype, maybe I'll have to rewrite from scratch again.
Are they concerned about storage? Storage is cheap. Are they concerned about time wasted on versioning? It takes less time then the cursory email checks. If they are re-writing bits then source control is even more important to be able to reference old bits.
I don't want to pollute the Source Control with incomplete versions.
That's actually a good concern. I used to think the same thing at one point and avoided checking in code until it was nice and clean which is not a bad thing in and of itself but many times I just wanted to goof around. At this point learning about branching helps. Though I wish wish SVN had full support for purging folders like Perforce.
Let see their arguments:
I'm the solo developer of this project.
It's just a prototype, maybe I'll have to rewrite from scratch again.
I don't want to pollute the Source Control with incomplete versions.
First, the 3rd one. I can see the reasoning, but it is based on a bad assumption.
At work, we use Perforce, a centralized VCS, and indeed we only check in source that compile successfully and doesn't break anything (in theory, of course!), after peer review.
So when I start a non trivial change, I feel the need to intermediary commits. For example, recently I started to make some changes (somehow, in solo for this particular task, so I address point 1) on a Java code using JDom (XML parsing). Then I was stuck and wanted to use Java 1.6's built in XML parsing. It was obviously time to keep a trace of the current work, in case my attempt was failed and wanted to go back. Note this case somehow addresses the point 2.
The solution I chose is simple: I use an alternative SCM! Although some centralized VCS like SVN are usable in local (on the developer's computer), I was seduced by distributed VCS and after briefly testing Mercurial (which is good), I found Bazaar better suited to my needs and taste.
DVCS are well suited for this task because they are lightweight, flexible, allow alternative branches, doesn't "pollute" the source directory (all data is in one directory at the root of the project), etc.
By making a parallel source management, you don't pollute the source of other developers, while keeping the possibility to go back or quickly try alternative solutions.
At the end, by committing the final version to the official SCM, the result is the same, but with added security at the level of the developer.
I'd like to add two things. With version control you can:
Revert to last version that worked, or at least check how it looked like. For that you would need SCM which supports changesets / uses whole-tree commits.
Use it to find bugs, by using so called 'diff debugging' by finding commit in history that introduced the bug. You would want SCM which support it in automated or semi-automated fashion.
Personally, I often start version control after the first sucessful compile.
I just wonder why nobody mentioned distributed version control systems in this context: If you could manage to switch over to a distributed system (git, bazaar, mercury), most arguments of your second group would become pointless since they can just start their repository locally and push it to the server when they want (and they can also just remove it, if they want to restart from scratch).
For me, it's about having a consistent process. If you are writing code, it should follow the same source control process that your production code does. That helps build and enforce good development practices across the development team.
Categorizing the code as a prototype or other non-production type of project should just be used to determine where in the source control tree you put it.
We use both CVS (for non .NET projects) and TFS (for .NET projects) where I work, and the TFS repository has a Developer Sandbox folder where developers can check in personal experimental projects (prototypes).
If and when a project starts to get used in production, the code is moved out of the Developer Sandbox folder into it's own folder in the main tree.
I would say you should start adding the source and checking in before you even build the first time. It is then much easier to avoid checking in generated artifacts. I always use some source control, even for my small hobby hacks, just because it automatically filters the relevant from the noise.
So when I start prototyping I might create a project and then before building it I do "git init, git add ., git commit -a -m ..." just so that when I want to move the interesting parts I just clone over using git and then I can add it to the subversion repository or whatever is used where I am working at the moment.
It's called branching people try to get with the program :p Prototyping? Work in a branch. Experimenting? Work in a branch. New feature? Work in a branch.
Merge your branches into the main trunk when it makes sense.
I guess people tend to be laid back when it comes to setting up source control initially if the code may never be used. I have projects I coded belonging to both groups and the ones outside source control are not less important. It is one of those things that gets postponed everyday when it really should not.
On the other hand I sometimes commit too seldom complicating a revert once I screw up some CSS code and not knowing what I changed e.g. to make the footer of the site end up behind the header.
I check-in the project in source control before I start coding.
The first thing I do is create and organize the projects and support files (such as .sln files in .NET development) with the necessary support libraries and tools (usually in a lib folder) I know I will use in my project.
If I already have some code written, then I add it too, even if it is an incomplete application. Then I check-in everything. From there, everything is as usual, write some code, compile it, test it, check-in it...
You probably won't need to branch from this point or revert your changes, but I think it is a good practice to have everything under source control since the beginning, even if you don't have anything to compile.
I create a directory in source control before I start writing code for a project. I do the first commit after creating the project skeleton.
i'm drunk and and i do first git -init and then vim foo.cpp.
Any decent modern source control platform (of which VSS is not one) should not in any way be polluted by putting source code files into it. I am of the opinion that anything that has a life expectancy of more than about 1/2 an hour should be in source control as early as possible. Solo develpment is no longer a valid excuse for not using source control. It is not about security it is about bugs and long term history.