Main Area and Open Discussion > General Software Discussion

Versioning Systems, for Small Enterprise ...

<< < (2/4) > >>

f0dder:
barney, it might take a bit getting used to using a VCS, but even for a single-person "team" it's not overkill. Yes, it's going to be slightly cumbersome remembering to do commits, doing them often enough, writing commit messages etc... but after a month it'll be pretty automatic for you, and you'll thank yourself plenty when you screw up, or need to backport fixes for a released  branch :)

I've been using subversion for quite a while myself, and it's a pretty decent system - but I'd suggest you pick up a DVCS instead, probably opting for Mercurial (git really works best if you're willing to mock around in a command prompt, and I sense that's probably not what you're after :)).

A Distributed VCS might sound even more overkill than a normal VCS, considering you're a single guy, but there's a couple of advantages. One is that local commits are very fast, whereas subversion takes a few seconds even on a gigabit lan. Branching and merging are faster and work better. And (at least for git, but I think mercurial as well) you have a single repository folder, whereas subversion sticks a .svn folder in every subfolder of your tracked project.

barney:
Oh, no, that's not a problem.  I used VSS for years, then migrated to WinCVS (?) when I left MCI.  The overkill to which I referred is the overhead of the revision system.  I'd just like something a bit less resource intensive than [I assume] the current products are.  I could always go back to WinCVS, but I was never wild about that implementation, and the more I ponder, the more I like the idea of something on a thumb drive.  I'm trying at the moment to set up SVN that way, with RapidSVN Portable as a client, although it appears that Mercurial might be better suited, or perhaps Bazaar.

Yeah, on line repositories would work - I could even set one up on my own site - but I might not be always on line when I want to work.  On line strikes me as better suited for backups & storage.  In that light, a DVCS would make even more sense, but methinks I need to walk before I start any marathons <chortle />.

Oh, the other reason for wanting a thumb-drive installation is that I won't always know what OS I'll be working on, so server-based access from a thumb drive would seem to be a practical approach.  I will, of course, live with whatever constraints come to be, but that doesn't mean I can't push the limits a bit <chuckle />.

Edit:  that overhead mentioned might just be due to the VSS experience - never had cause to check it with WinCVS.

Eóin:
Well I consider the msysgit and TortoiseGit combo to be really intuitive and easy. Definitely worth looking into.

f0dder:
Resource intensive?

Both subversion and git (and, I wager, mercurial and bazaar) only take processing power and memory when you're doing versioning operations (the Tortoise* shell integration family does keep a caching process running, but it's overhead is negligible, and it helps speed stuff up). The disk overhead isn't really bad either, as all versioning systems try to minimize the redundancy - some systems store changesets (with the occasional full-file snapshot to speed things up), whereas git stores all files in their entirety, but only has one copy of each unique file content (based on SHA-1 hash of files). Disk space is cheap anyway :) (and you probably aren't going to have databases or .psd graphics under version control? :)).

Be careful with thumb drives, and definitely do not use one as the main source of your repository. There's no telling which quality flash memory they contain, they get lost easily, the electronics might fry, et cetera. Having a thumbdrive as an additional (backup) location isn't a bad idea, though - and this is probably easier to achieve with a DVCS then a traditional CVCS.

In that light, a DVCS would make even more sense, but methinks I need to walk before I start any marathons <chortle />-barney (February 28, 2010, 05:15 PM)
--- End quote ---
Probably easier to start with a DVCS than learning and then unlearning a CVCS... for single-developer usecases, the differences aren't that big, really - basically, commits go to local storage, and if you want serverside you "push" :)

barney:
f0dder,

The more you write, the more I think I'm approaching this from the wrong vector.  'Course part of that could be because I'm in the midst of reading installation/usage instructions  :-\.

When I was using VSS, it had a significant footprint, running in the background.  But, as I said, that was years ago.  And -also years ago, just not so many <chuckle /> - there was a footprint from WinCVS, or so it seemed.

However, after reading the instruction set for SVN and your comments on learning, then unlearning/relearning, methinks I've adopted the wrong approach.  Luckily, that is something that is relatively easy to change at this stage.

As you say, disk space is cheap, and I have a lot of it free, for the nonce.  My use of the thumb-drive is not for long-term storage, but for convenience.  If I can take it (the files) with me, I'm not reliant upon a network being available when I need it - or said connection being fast enough to be worthwhile.  Long-term storage will be on both a local hard drive and on the NAS drive, as well as periodic backups to DVD.  I currently use SyncBackSE to perform data backups, including the thumb-drive, on a daily basis, with system [restore] backups weekly.  So I'm not too concerned about the thumb-drive data being lost.

<Sigh />  Looks as though I need to change directions and start researching DVCS entities.  Hopefully I could set the VCS primary on the server, then the DVCS on the thumb.  Oh, well ... back to search <ouch />.  Prolly Mercurial & Bazaar 1st, then wherever the engines take me.

Thanks!

Navigation

[0] Message Index

[#] Next page

[*] Previous page