[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Sparse Directories vs Externals

From: David Weintraub <qazwart_at_gmail.com>
Date: Wed, 25 Feb 2009 17:35:27 -0500

On Wed, Feb 25, 2009 at 10:08 AM, Robert Dailey <rcdailey_at_gmail.com> wrote:
> I have two options I can take:
>
> 1. I can keep the local changes on my hard drive and wait the 3 or 4 days it
> takes to implement the feature and then check it in that way. Of course, I
> would do updates along the way to make sure resolving conflicts does not
> overwhelm me all at once.
>
> 2. I can create a branch, implement the feature, and then merge it back over.
> I'd also ensure that I merge changes from trunk to my branch every day to
> keep conflicts at a minimum.
>
> Immediately number 1 and 2 seem just as functional but 2 has more "steps" to
> take. However, #2 has the added benefit of acting as a backup. What if my
> hard drive crashes when I'm using method #1? I will lose all of my work!
> However, if I am using #2 at least I have *something* saved.
>
> How does everyone feel about this point?

This is actually an argument that users of Git make why distributed
version control is better. With Git, instead of creating branches, you
can simply declare your own repository, and version control with that.
When you finish, you can deliver your stuff to the repository where
you got your code from.

Of course, that doesn't handle the whole "backup" issue if the drive
with your repository crashes.

I use Dropbox (http://getdropbox.com) for all sorts of tasks, but I
never considered using it as part of my Subversion working directory.

For those who haven't heard of Dropbox. Dropbox synchronizes a local
directory (usually called $HOME/Dropbox on Unix or %USERPROFILE%\My
Documents\Dropbox on Windows) to the Dropbox server. The Dropbox
directory is local on your system, but all changes are almost
instantly sent to the Dropbox server.

You could (in theory) use the local Dropbox directory on your machine
as your Subversion working directory. That way, you are constantly
backing up everything you do. If your hard drive does crash, you can
simply reinstall Dropbox, sign on to your Dropbox and get back you
Subversion working directory right where you left it.

You can also share your Dropbox between various computers. Mine is
shared between my Linux desktop, the Virtual Windows machine that is
running under my Windows desktop, my notebook computer, and my Mac I
have at home. This would allow you to leave work, come home, and then
simply continue in Subversion where you left off..

Dropbox also versions all the files you save and even allows you to
retrieve files you deleted. That would allow me to revert back to the
version of the file as it was two hours ago without checking it in.
Something I always wish I could do.

As I said, I don't even know if this would work, or even if Dropbox's
license agreement will allow so much traffic. However, there are other
types of backup solutions like Mozy that do similar tricks
(automatically synchronizes your work with a backup server), and if
you're working on a Mac, you could use Time Capsule for similar
results. I am sure there are similar systems for Windows and Linux.

Anyway, the real solution isn't version control, but backup.
Considering the low cost of diskspace, I am surprised that more
businesses don't bother with backing up user desktops. That's where
much of the company's living documentation sits. All it takes is one
developer to be down for a couple of hours while they try to recreate
their environment to more than pay for the system.

--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1229347
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-25 23:36:21 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.