Main Area and Open Discussion > General Software Discussion

alternative to filehamster?

<< < (21/25) > >>

tomos:
^ "[FileHamster] is set to make revisions not more often than every 5 minutes"
I didnt know you could regulate that in FH, must check it out.

For me, FileHamster is worth using (and worth reporting bugs etc. in their forums) because I can save a comment with each file-version saved so I know what I'm restoring if it comes to that (and it has).
I have comment window set to show for each save, if that doesnt show, I know something is up. Without this setting, you wont notice if something has not backed up, which, as already said, is not on...

f0dder:
Tranglos,

IMHO you're missing out on the benefits of version control. It's not just about "having a place to stuff previous versions", it's a lot about workflow as well. A bunch of backup zip files don't tell you very much about the state of the project, and makes it difficult to easily and quickly spot exactly what has changed between versions.

Working with a versioning system forces you into the habit of being more organized - instead of scattered changes across your entire project, you learn to apply focused changes to a handful of files, and then commit that changeset along with a meaningful commit log. It's makes it a lot easier managing your projects in the long run, and a lot easier to track down exactly when that nasty regression bug was introduced.

If you work with a decent DVCS with cheap branching support, it also makes it a lot easier to work on feature branches. Currently working on adding some new feature that might take a couple of days to implement, when you realize there's a nasty bug you should really prioritize instead? Simple, make a new feature branch for the bugfix off your latest stable commit, fix the bug there and release - then return to your new-feature branch. Organized, without clutter, without the large risk of errors if you tried to handle this workflow manually.

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.-tranglos (July 24, 2011, 01:42 PM)
--- End quote ---
Do a bit more of pre-planning ;). It does happen I end up renaming a class, but it definitely isn't very often - not even newly started projects. Adding files happens a lot more often, but that's painless even in SVN.

t'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.-tranglos (July 24, 2011, 01:42 PM)
--- End quote ---
No tool will help you with that, it requires solid engineering... keeping a decent level of abstraction where implementation changes doesn't affect the clients, and a lot of care and consideration when applying changes. It's not easy, and even if you get it right it can be nearly impossible to go back and build an exact copy of a previous version (which can be necessary if you need to deal with bugs in older versions).

tranglos:
^ "[FileHamster] is set to make revisions not more often than every 5 minutes"
I didnt know you could regulate that in FH, must check it out.
-tomos (July 24, 2011, 02:51 PM)
--- End quote ---

The option is called TimeDelayBetweenRevisions, in the "Document" section of the Options dialog. FH will wait at least this long before making a new revision. Useful if you hit Ctrl+S compulsively but don't want to have revisions made every 20 seconds or so :)

There is of course a potential problem scenario:

1. Save your file (revision is made)
2. Make some more changes in the next minute or so
3. Save the file (revision is not made - file saved too soon after last revision)
4. Close your document.
Result: the last revision FH made is NOT the final version of your file.

As I understand it, FH handles such situations well: after TimeDelayBetweenRevisions has elapsed, it checks the file and creates a revision if it has changed. At least I think it does - a simple experiment will verify.

kyrathaba:
I confess I don't always use a version-control system when programming.  I know I should, except for the smallest of tasks, but in practice I have only done so for relatively larger projects -- say, those that will take me several hours to code.  For smaller stuff, when I take a break after polishing a particular function or whatever, I zip the dev directory and back it up to an external drive and to my SkyDrive account.

"But that takes longer than a quick commit with SVN!" I hear you argue.  True, but setting up a SVN-local-repo-to-online-repo pair is a bit more annoying for me personally than using the above slightly more clunky system.

mouser:
Regarding AutoVer, I'm definitely going to try it soon, but posts about version 2 beta on their forum made me feel like i should wait a bit.

Right now i've uninstalled FileHamster and I'm using the new file monitoring and versioning ability added to Super Flexible File Synchronizer, an excellent backup/synchronization tool which has been written about before.  It seems to be working well, and is convenient since I already use SFFS for normal backing up (mirroring) other folders on my system.

Navigation

[0] Message Index

[#] Next page

[*] Previous page