Main Area and Open Discussion > General Software Discussion
alternative to filehamster?
mouser:
At the risk of repeating myself: make the jump and use a full versioning system like.. You are doing yourself a favor, the mentioned systems do not drain resources from your PC (or brain for that matter) and provide a good base to work more structured at home.
--- End quote ---
I agree that coders should be familiar with versioning systems. But I disagree that these are suitable for keeping large volumes of (source and non-source files) versioned instantly, for a couple of reasons.
Versioning software is designed to be run on command when you have some new good changes to commit.
You commit an update when you have made a bunch of changes and you are saying "here is a new state of the system". If it goes wrong you can roll it back.
While that makes a lot of sense for software development. But I believe there is value in a much more frequent silent backup of changed files as you are working on them.
In this scenario, one is interested in saving virtually every change to a file automatically, so that you can do an emergency rollback or comparison if it turns out you broke something at some point, combined with periodic cleaning of old backups.
I don't think version control software is well set up for this use. Not that you couldn't use a version control system to try to simulate it, but think about what that would mean -- having version control scan a multi gigabyte drive/documentfolder for all changes, every 2 minutes and creating a new commit every 2 minutes, etc. That's just not practical with any version control system I know of, and this kind of automatic rapid backup is key to being able to recover from unexpected problems -- you do not simply want to be able to rollback to the last manual commit you remembered to run.
So i'm not against version control systems at all (especially but not solely for muli-user systems).
I'm just saying that there is a use for a separate system that is live-monitoring for any changes to your document files, and doing an instant versioned backup of changed files, for emergency restoration/comparison features.
tranglos:
I don't think version control software is well set up for this use. Not that you couldn't use a version control system to try to simulate it, but think about what that would mean -- having version control scan a multi gigabyte drive/documentfolder for all changes, every 2 minutes and creating a new commit every 2 minutes, etc. That's just not practical with any version control system I know of, and this kind of automatic rapid backup is key to being able to recover from unexpected problems -- you do not simply want to be able to rollback to the last manual commit you remembered to run.
-mouser (July 24, 2011, 11:37 AM)
--- End quote ---
That's one good reason, here's another: I admit I've only tried SVN, but once you commit to it (pun intended), you lock yourself out of your preferred file manager. File renames, file deletes or moves must be done through SVN only. This riles me to no end, particularly at early stages of a code project, where frequent renaming and rearranging files is part of the process.
I found that I cannot live with this, especially as SVN's right-click menu is so much inferior to the ease of use I have in Total Commander... but even Windows Explorer is preferable to **that**.
So my version control consists in manually zipping up a source code folder and naming the zip file with the date and build number. I have a personal rule that says only zip up the folder if the code compiles (known bugs are OK). Using SVN's file management is just too much of a pain.
TC can search and run a comparison on files inside zip archives, so if I do need to compare or merge, which is quite rare, I can still do it with zip files.
I can understand using version control in team scenarios, but at best it would be a necessary pain. No way would I ever voluntarily use such a cramp-inducing environment for anything else.
mouser:
Version control systems have gotten a LOT better in dealing with new and moved files/folders.. i remember learning how to handle such things in the original version control system cvs and feeling an instant need to get blackout drunk. I don't think i ever touched cvs after that day. But it's still a big pain, and tranglos' point is valid in terms of why version control is not ideal for some backup scenarios.
f0dder:
I can understand using version control in team scenarios, but at best it would be a necessary pain. No way would I ever voluntarily use such a cramp-inducing environment for anything else.-tranglos (July 24, 2011, 12:27 PM)
--- End quote ---
Unless you're doing some very wacky stuff to your source code folders, the annoyance of having to go through svn (or git or hg or bzr or ...) commandline utils or whatever GUI tools is minimal compared to the benefits you reap. Like mouser, I wouldn't recommend using it for non-development stuff, but for development stuff? It's a no-brainer, really, even when you're not working in a team.
tranglos:
I can understand using version control in team scenarios, but at best it would be a necessary pain. No way would I ever voluntarily use such a cramp-inducing environment for anything else.-tranglos (July 24, 2011, 12:27 PM)
--- End quote ---
Unless you're doing some very wacky stuff to your source code folders, the annoyance of having to go through svn (or git or hg or bzr or ...) commandline utils or whatever GUI tools is minimal compared to the benefits you reap. Like mouser, I wouldn't recommend using it for non-development stuff, but for development stuff? It's a no-brainer, really, even when you're not working in a team.
-f0dder (July 24, 2011, 01:08 PM)
--- End quote ---
I guess where we disagree is whether the inconvenience is really minimal viz. the benefits. As a single, hobby developer, I feel I'm getting very little from source control, while renaming files is something I do several times a day, esp. as I progressively get a better understanding of how my classes need to be designed and laid out.
The main area where I would like to see **some** benefits is a common situation where you have several projects all of which use the same core library - all the utility code you develop as you go and expect to use in pretty much everything you write. This is the only scenario where I have been bitten hard: working on a new project B I make changes to the library which break an older project A. And I only find out about that when I try to build project A, months or years later. It's nearly impossible in practice to match a stored state of the library with a stored state of a project. When I realized SVN wasn't helping with that at all, that was when I gave up on it entirely.
(But I've veered quite off the thread here. Obligatory OT: I'm still using FileHamster, haven't noticed it missing any files, but then I have never needed to revert, so far :) It's set to make revisions not more often than every 5 minutes. I think I'm tolerating it only because I almost never need to interact with it...)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version