Dropbox + TortoiseSVN; Where is the advantage? (New to SC)

This topic is 1185 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hey. I am relatively new to source-control.
I previously had a Git-Ext and Bitbucket set up for our project, however with a limit of 2Gig we needed something larger and cheaper.

I have set up TortoiseSVN using Dropbox as a repository. Now; whenever I commit or change a file it will instantly update in Dropbox.
But same thing would in theory happen if I had changed or added files directly to a dropbox, as dropbox automatically update any recent files anyway. So right now, Tortoise feels like just doing the same thing twice, to get a file in a share dropbox folder. It doesn't exactly feel logic to me at the moment.

A dropbox folder is automatically copied and stored local on your computer anyway, with a real time update.

I understand Tortoise could perhaps help revert changed files, or hold back files you don't want to update yet. But at the moment I'm not entirely sure where the true advantage lies, using Dropbox and TTSVN together.

Does anyone else use them together, and what are your experiences?
Also do you have any advise to give a newbie to Tortoise. I've only used Perforce in the past, but hasn't been involved in its setup.
I am the only one on my team who has any (and it's very limited) experience using Source Control, so unfortunately at the moment I can't get much help from my team mates.

Cheers.

Share on other sites

I just use BitBucket with Hg, so I can't comment on SVN, but I have some thoughts:

A) It's nice to be able to see diffs of two different commits. DropBox doesn't easily allow that.

B) It's nice for different programmers on the same project to not be simultaneously editing the same repository, if you solely went with DropBox. So having a 'working repository' separate from the 'committed repository' is a plus, even if that just means using one Windows file and only copying it into DropBox when you're sure it builds.

C) It's nice for your teammates not to get spammed by TempFileX.cpp was just updated. TempFileX.cpp was just updated. TempFileX.cpp was just updated, for every single time you hit Ctrl+S, so that's another reason not to use DropBox as the working repository.

Share on other sites

If you must stick with the SVN+Dropbox route, I believe the benefit lies in the SVN server being in the Dropbox folder so that it is accessible to others.
I believe your working copy stays elsewhere on your computer and you don't run into the "TimeFileX.cpp was just updated" spam or conflicts when two people edit a file.

I would not personally use or recommend hosting a version control system on Dropbox.

Share on other sites

You will not really understand the benefits of source control until you need them and then you will be happy you use it.

1) You are in the middle of a load of changes and realise it was a bad move and you have boxed yourself into a bad space. You can just roll back to before the changes and no foul and look for a better way :)

2) You find a bug that was introduced recently. You can look at the change log to see exactly what happened and even who caused it.

3) You can see all the current pending changes you have made and quickly review them

...

The uses are numerous and subtle. Coding without source control is like driving without a safety belt on. Fine until that time you need it :)

Git is a better option for some dropbox type of usage due to the distributed nature of GIT. You would hold your master on dropbox and only push to the master when you know safe to do so. Also if you do damage the master each dev has a valid repo copy.

With SVN there is a single repo so if you damage it you are stuffed. If you are the only person that updates code the risks are low but if you are using to sync between a number of people you will damage your repo quicker than you can ask "Has dropbox synced yet?"

Working the way you are the risk points are.

1) You commit and then close down before the repo has fully synced everything to dropbox

2) Someone else commits and you interact with the repo before either their and your dropbox have fully synced all the changes

3) Two people commit at similar time and then both their dropbox copies try and sync at the same time... bang!

The SVN repo is stored as a large collection of complex control files and if you interact with them in an inconsistent state you will get bad and potentially fatal damage in your repo.

Share on other sites

If you must stick with the SVN+Dropbox route, I believe the benefit lies in the SVN server being in the Dropbox folder so that it is accessible to others.
I believe your working copy stays elsewhere on your computer and you don't run into the "TimeFileX.cpp was just updated" spam or conflicts when two people edit a file.

I would not personally use or recommend hosting a version control system on Dropbox.

SVN+Dropbox was not my pref. choice. We started using Bitbucket, but uploading the project already took up 800MB. For some reason bitbucket said our repository was 1.8gb. So we need something bigger.

Right now, I'm working on the project full time, which means I have no income what so ever. I did have a look at the SVN with large storage thread on the forum,  but paying $24 a month for like 5GB is just not anything I can afford, especially not as we estimate our project to be around 8GB. (It's a 3d Game) Ideally I wanted to set up SVN on my NAS, however I've spent an entire week on trying to set it up and I really don't wish to spend anymore time trying (and failing) setting up Source Control. I am not a programmer, and unfortunately most guides how to set it up are written by programmers - so command codes are thrown around and I don't even know where to input them, so most of the times I get stuck. Tortoise and Dropbox seemed fairly simple and easy for the time being. I'm an artist with production management experience, so my knowledge of any of this only extend to how to use production management software, now how to set it up. I appreciate all the feedback you guys have given me! Due to time differences it's very rare more than 1 person is working at the programming at the same time (lucky) so I hope none of these risks you all mention will happen. I appreciate you mentioning them, and I will definitely keep it in mind and create backup of our work frequently. For now, unfortunately we have to stick with this system until/if we get another person who's more experienced in Source Control into our team. Share this post Link to post Share on other sites We started using Bitbucket, but uploading the project already took up 800MB. For some reason bitbucket said our repository was 1.8gb. So we need something bigger. Do you understand that source revision controls store previous versions of files you are working on, including files you've deleted in later commits? For BitBucket, I've personally separated my project's source code from my art assets and level data and etc... i.e. my game's code and my game's content I'm backing up separately. I'm not sure if this is what would be recommended by professionals though. Share this post Link to post Share on other sites For BitBucket, I've personally separated my project's source code from my art assets and level data and etc... i.e. my game's code and my game's content I'm backing up separately. I'm not sure if this is what would be recommended by professionals though. This is common practice around my circles. I rarely hear about code and assets being in the same repo. It reduces noise when searching through commits, and programmers may not care about a hundred megs of art content that isn't relevant to their task. Share this post Link to post Share on other sites For BitBucket, I've personally separated my project's source code from my art assets and level data and etc... i.e. my game's code and my game's content I'm backing up separately. I'm not sure if this is what would be recommended by professionals though. This is common practice around my circles. I rarely hear about code and assets being in the same repo. It reduces noise when searching through commits, and programmers may not care about a hundred megs of art content that isn't relevant to their task. So if the OP takes that route, then nothing prevents him from sticking with BitBucket - his *code* won't reach 2 GB. He'll still need some way of backing up art assets - which could just be DropBox and regular backups to an external harddrive. Share this post Link to post Share on other sites I understand Tortoise could perhaps help revert changed files, or hold back files you don't want to update yet. But at the moment I'm not entirely sure where the true advantage lies, using Dropbox and TTSVN together. Show changes compared to other revisions, "blame" a particular line changed to some specific commit, revert a file, an entire folder, the entire project, have different branches dealing with development of different features (although SVN isn't the best thing to do that), and commit messages since they're a good source of documentation if you do them properly. Share this post Link to post Share on other sites Putting a source control repository on something like drop box is likely asking for trouble the moment you only get a partial sync for some reason, or multiple people try to "commit" before it syncs. I wouldn't even be surprised if it corrupted the repository including previous changes. Anyone know what the size limit is on github? It's$7/month for individuals to have 5 repo's or \$25/month for businesses to have 10 repo's, but can't see any limited on the size of a given repo. Would also want to check what the restriction on "personal plans" is, there a lot cheaper and as far as I can tell, the only limitation is you can't have any complex restricted permission system, people either have access or they don't.

If you must avoid that, Id host a SVN/GIT/whatever repo on one of my own "server" systems, then just use dropbox or other cloud storage system as a place to put the repo backup's say once a week incase my "server" was to die. This way the repo is running on a proper file system with no risk of potentially unpredictable cloud syncs corrupting it.

EDIT:

Also generally, a lot of the "big files" I see in projects don't need to be under version control. e.g. none of your build output (exe's, dll's, etc. or complete installer packages like .msi, .rpm, etc.), none of the intermediate build files (e.g. .o files) and various other cache/misc files the IDE and toolchain might create (e.g. Visual Studio .sdf and .pch files). This can cut down a fair bit on the required repository size, although in games I tend to find the source audio files and graphics files are also pretty big, and I wanted those version controlled.

Edited by SyncViews

1. 1
2. 2
3. 3
4. 4
Rutin
13
5. 5

• 26
• 10
• 9
• 9
• 11
• Forum Statistics

• Total Topics
633694
• Total Posts
3013372
×