I often find myself working on two different computers in different places and i was wondering how to share as much as possible between these PCs with the least issues possible.
At the moment i'm using dropbox to share the projects i work most often on (2-3 projects, so no big deal) but my whole workspace is actually bigger than my dropbox space.
What i would like to do is to share all my projects, Eclipse and also the working environments (or at least the databases) and i was thinking to either use an USB hard drive or a repository to do this. There are a lot of issues i can think of about this and i'm pretty sure there are even more issues i haven't thought of:
First of all i know one day i'll forget the hard drive home when going to work and i'll screw up a job day by going back and forth between home and my office so using the repository sounds like a better idea
How bad can be to share database and IDE files? Though my computers run Windows 7 and 8 and both have a 64bit architecture i reckon that sharing such things might lead to bad behavior or things simply not working (for example if somehow one my PCs will assign a different drive letter to it things might not work and i'll have to manually assign it, leading to a waste of time).
Also using a repository for this might not be ideal since it might create a lot of useless versions. I'd love to not have to configure and upgrade each IDE separately and to not update databases manually but i can live without this feature as long as i can share my projects
In case i use an USB hard drive and put even Eclipse and the databases in it, how bad it could be performance-wise? I'm pretty sure using an USB drive will affect performances a lot
A lot of the projects i work on already use a repository, I have projects using Git, SVN and Mercurial. Should i use one of these to share all my projects how will interfere with already existing repository information?
Am i right in thinking that sharing a whole Eclipse workspace (so including will cause issues if the paths between the 2 computers are different? I might have to set thing up differently for each PC (for example if i use external programs and libraries, such as Android SDK, they might be in different places)
And i'm sure there will be more on this. So, my questions are:
1) Is it possible to share IDE and databases (that is, without using periodic import/export) between two PCs without issues or is it better to just share workspaces or even just single projects?
2) Taking into account the issues above, what's the best strategy to share files? I can accept different ways to share files than the two i thought of.
I think you can have an identical IDE installed on computers (All the configuration should be the same, you can configure your Eclipse and zip the Eclipse files copy it on another computer then you have an identical IDE) also using maven as build tool makes it easier for you to share project between IDEs (on paper, you even don't need same IDEs) and for the workspace i guess the best solution would be a source control system,having share folders/usb drives can easily end up in mess.
Related
Hi
Since I'm always transferring files, primarily plain text for coding, between home and office, I was wonder if other coders would share their preferred method for doing this. Is version control, checking in and out, really the best way to sync remote data, or is there some other solution (ie 3rd party cloud based tools like drop box or...)
Would luv to get other people's opinions on this subject...
When sharing files and source across more than one machine there is always the possibility to loose something when not using some version control. I personally use git (a distributed version control system, actually, just the stupid content tracker) for everything, especially for stuff that is live on many machines.
The benefits of a light and distributed version control system are:
Obviously, the versioning ;)
Consistency gets checked.
You retain a history of all your changes.
You can flexibly branch and merge as you like, w/o running into trouble when having too many parallel trees you sync manually.
You get to know version control, especially, you get to love distributed version control.
You can literally share a repository with others, who in turn can branch/merge at their own leisure.
Even when using version control, you are still free to have snapshots lying around w/o any version control ;).
So, I am strongly against manually managing synchronization - even in a one-man-show of a project.
I'm a grad student in Electrical Engineering, and my lab has various projects related to ultrasonics. We have lots of code to perform simulations, but right now our situation is such that any given script has ~5 different versions. In addition, one person might develop code to simulate wave propagation, while another needs that code to perform a different simulation. This results in code being emailed back and forth quite a bit.
I suggested version control to my advisor, and she says that she likes it, but doesn't have time to manage a VCS, so it would have to be set up in such a way as to require as little maintenance as possible. Obviously, we're not releasing software to the public, so it doesn't matter if the internal structure is unconventional.
Most of the lab are not professional coders, but we all need to write MATLAB code as well as some other stuff. So, I don't expect the users to be so good about clean commits and the like, so it would be good for everyone to have their own "workplace" or something like that. But to be honest, I've only ever used version control for 3 people at once, so I'm not sure how to set this up.
So I am asking what is the best way to do this. I have only used Subversion, but I wonder if that is the right choice. We need a system that would (sorted by importance, descending):
require little maintenance
be easy to use and learn, since not everyone has used version control
have shell integration (we all use Windows XP)
be easy to set permissions and give everyone their own workspace
be easy to set up and get running
So, (1) What VCS is the best choice, and (2) how should we structure it. Thanks for the help.
We use subversion and love it, for its simplicity, easy of use, integration into the shell environment and the ability to not just version, code, but also specification documents pdf's and other resources we have.
As for structuring it, try and use your logical structure, as close as possible. Keep it simple :)
I see no reason why you should look further from Subversion. Although, for extra little maintenance you could check GitHub (since it is hosted solution, so no worrying about backup, servers etc) but there are hosted Subversion repos as well.
Especially if you're already familiar with it, so you can bring others up to speed and get extra credit :)
Once completely setup subversion should require very little maintenance, it's model is simple to apprehend, it is integrated in the shell, it supports ACLs which work just fine and it's setup is well documented.
you can setup subversion in a webserver, integrate it with a windows domain for auth if needed (otherwise you have to add/remove users, change passwords on the svn server)
You could also go the distributed vcs way, with hosted solutions no server setup, but to get that across your user's mind is gonna be way more difficult than svn. Not to mention getting it across your own head first.
Unless you have complex, fast-paced, parallel development models, I wouldn't recommend dvcs, I would stick to SVN
I agree that subversion is a very good choice.
But you can also consider mercurial: it's easier and it also has a tortoise integrated interface.
I would recommend www.assembla.com. They offer paid subscriptions but for academic projects you can apply for a free pro account.
I have used it for my academic projects and was 100% satisfied by the ease of maintenance, up-time and simplicity
The far easiest way is to use Subversion. But to get it to work the most easiest way (under Windows) you should definitely use TortoiseSVN.
After installation it works right within the explorer is just one right click away from usage. Maybe one of your guys should take a deeper look into the whole documentation to give help if needed. All other guys should take a look into the Daily Usage Guide for a first start.
Also you should take care about how you structure your repository!
Subversion has too many limitations related to the "always online + central server" model.
I would strongly recommend using a distributed version control system.
From the three main ones Git, Mercurial, Bazaar; in my experience Bazaar is by far the easiest one to use and setup.
I've been developing my first iPhone app part-time and would like to start using a more rigorous form of version control than I've been using over the past four months, i.e. copying source code folders to another directory and time stamping them.
I've used SourceSafe and Team Foundation System but I don't have a good idea of what version control systems (VCS) are available for the Macintosh. I've seen ads on SO for a Subversion front end but would like some other options.
Here's a list of my initial requirements:
Runs locally under OS X Leopard 10.5.7
Integrates with XCode 3.1.3 (if no integration, user-friendly interface)
Basic VCS features - check-in comments, branching, pinning
Advanced VCS features like build automation or reports would be nice but not critical at this time
Ability to handle multiple developers down the road (6-12 months)
Thanks in advance for the help.
Mercurial would be my pick for version control for a project starting as a solo project if you don't want to set up a dedicated server. Mercurial requires no server because it's a distributed VCS, every working copy is also a complete repository, so once you've installed Mercurial you are ready to go, just type 'hg init' in the root directory of your project and you're off.
It's perfect for working alone or with a small number of developers (i.e. no IT staff or sysadmins available), it has a utility that lets you quickly set up a temporary server for your local repository so when you meet up with people it's easy for them to clone the repository or share changes. You can also just give people copies of your repository over email or USB key or copy them over the network or whatever and reconcile changes to the copies against each other later.
For me Mercurial made the difference between actually using a VCS for personal projects and just giving up because it's too much trouble. Setting up a Subversion server locally isn't a huge deal but it's still enough trouble to make me not bother, and if you really want to be thorough you'd want to think about how to do proper backups, etc. With Mercurial at any point you can just back up your working copy to other media and you have a backup. I don't know if this really makes sense but Mercurial is a VCS that you can use casually and informally thanks to the distributed nature.
No Xcode integration, but having used various VCS' with and without integration I don't think it's very important as long as good clients are available. These days I've mostly settled on just going command line and it's refreshing.
Perforce, IMO, is right out. Aside from being a commercial product it is obnoxious beyond belief. It requires you to be connected to a server at all times or things become a major pain in the ass. So if you just want to work on stuff from multiple machines in multiple locations or if you want to have people on the project that won't be on the same network all the time it's going to suck. Perforce just constantly beats you over the head with the fact you are using Perforce, no other VCS I've used is so in your face and annoying.
Git is another option with a similar feature set to Mercurial that might be worth looking at. In my case I also do Windows stuff and Git's Windows support is supposedly crap so I went with something that works on all my platforms.
Build automation IMO is the build server's job, not the VCS' job, so if you want build automation find an appropriate build server.
SVN or Subversion is included with Xcode and is well integrated with it. As you grow to have bigger needs, you can use third-party Subversion servers and use the same SVN support over the network. If you don't like SVN, I think XCode supports CVS too.
If you're looking for something adequate, cheap, and expandable, then just mosey on over to the SCM menu of XCode, and check out what's already there. If you need help setting up SVN, just comment.
IT looks like subversion would be your best choice for XCode as there is already some guidence on getting that up and running with XCode here. Subversion addresses all of the features you are speaking of. Pinning specifically is a feature of Source Safe; however subversion can do tagging. Build automation is not a feature of a source control system, but source control systems are typically used in continuous integration server scenarios. I have not used it but from what I understand Hudson is a continuous integration Server which is gaining popularity and momemtum. You can find more information on Hudson here and here
SubVersioN (SVN) fulfills (most of) your requirements.
I'd also put in a vote for subversion since XCode supports it natively. I've been using it myself and have been very happy.
However I'd question your requirement to run the server locally. Sure, you can do that no problems with subversion. But wouldn't you be nervous about your hard disk failing?
I've been using Beanstalk to host my source code. It's free for up to 3 developers, you'll be able to upgrade your account once you grow, its fast and it's SAFE.
I just looked in Xcode (3.2, though, so it may not be exactly the same) and the options for source control integration are subversion, CVS and perforce.
Outside of Xcode, there are a couple of very nice GUI clients for subversion for OS X.
Subversion would be a good place to start, it seems.
All the cool kids are using distributed VCSes these days, apparently. You might want to spend half an hour reading up on git or mercurial (hg - my preference). There's no direct integration with Xcode, but they're easy enough to get into.
Perforce is now free for up to twenty users, but will be expensive after that. You might want to check it out, however. Xcode no longer supports native Perforce integration, though there are scripts and a plugin.
I've used CVS and SVN. The problem I run into with both of them is that you have to explicitly perform all of the add/delete/update/move etc. operations using a tool that remembers those actions so that they can be committed. Tools like TortoiseSVN make life easier, but not as easy as I would like. IDE integration is nice, too, but I don't like be bound to do everything in an IDE. My problem is that I'll accidentally make updates or rename folders without using the appropriate tools, then my source gets messed up.
Is there a simple source control tool that will let me work however I want in a folder structure, and allow me to sync everything when I'm done?
I realize that this would make some features of traditional source control impossible, but I'd be fine with that.
Newer distributed source control systems like GIT, Bazaar, and Mercurial (aka: Hg) all tend to be better at detecting broad changes done in the file system such as moving directories, renaming files and even replacing large chunks of the file system.
From my reading, Bazaar and Mercurial were essentially built from the ground up to handle this sort of free-form editing specifically because of how explicit SVN required you to be.
Dropbox is a nice versioned source control-style app that requires a little setup and zero maintenance. Reverting to old versions isn't as efficient as the usual source control, and it tracks all your changes (you can't choose whether to commit).
Basically, you create a Dropbox folder on your computer, and everything you save is automatically synchronized. It's pretty fast (it reacts in minutes, not hours), and you get a gig or two of space.
So, you get less control, but it's super easy. I personally use it for my Password Safe database and my "to-do" list, so I can access them from any computer.
Even though you've had some issues in the past with SVN. I still think its the way to go. VisualSVN server provides a simple interface for setting everything up and there are a ton of free or low cost tools to use.
While this does not answer the question itself I'd strongly recommend training yourself in using the version control system of your choice for everything. Once using the VC system became a habit there isn't much risk in messing up your source folder accidentally anymore (of course, the human factor still remains) and you get much better logs when explicitly working version-controlled than any tool doing automatic change-tracking.
On Windows, TortoiseSVN is a really nice tool that makes it quite easy to not overlook the VC system.
(to give an analogy of training one self in using a VC system: if you manage to get yourself trained using touch-typing you don't know anymore how you managed to live without it. Happened to me several years ago when I decided that I should learn it at least to be able of judging the system. I really don't understand how I typed before.)
As for the renaming issue you might want to look into git. It can cope with renames / moves without using the VC system itself.
I am interested to know what strategies people have to keep their code AND work versioned across multiple machines. For example I have a desktop PC running XP, a macbook running OSX and VMWare running XP as well as a sales laptop for running product demos. I want to know how I can always have these in sync. Subversion is a possibility for this but i find it less useful for dealing with binary files - maybe I have overlooked something here. What do other people use as they must have similar issues? Do they keep all files on a USB drive and never on the local file system. I am not always online so remote storage is not really an option.
Like others have said, subversion is your best bet for code. For binary files/non-code, I find DropBox to be very convenient. It stores revisions, has undelete, easy sharing, etc. basically an automagic, web-friendly SVN. Not having to think about it is the biggest plus for me.
I use mercurial for keeping my workfiles in sync. It's not great for big binaries either, but it lets me commit without being online and makes it easy to branche/merge different versions.
Ah the old VCS Debate.
The simplest way to share/sync Source Code is to use some sort of VCS (Version Control System) - this gives you plenty of benefits over being able to keep things synced. There are many VCSs out there, I personally use Bazaar-NG and Subversion - though I'd suggest you trial a few and see how you feel using them.
For syncing general files, espescially if it's only for yourself, I'd reccomend using "DropBox" (http://www.getdropbox.com/) - I've been using this for the last week or so, and it makes syncing up my multiple machines with a certain set of files so much more easy.
It also has some extra features that'd probably be useful for collaboration too, but I haven't tried those out yet.
Subversion works just great in our office for sales, project management, design and code files.
I store my dotfiles (.zshrc, etc) in a Git repository that is checked out into my homedir. I also do the same for the LaTeX files comprising my classwork.
I put important builds in Source Control -- it's fine for binary files.
For most files including source code we do use Subversion. It's really great.
If there are larger files oder Project management related documents which are used by people who have no access to the source control system, we use Microsoft SharePoint.
This is especially usefull if you are working with people outside your company.
I keep all my work encrypted on a USB stick. It also has a bootable Linux partition so I can get into a sensible working development environment from any machine, such as a borrowed work laptop with some software to carry to a conference that I can't move to my own machine.
When you have more people working on the same code, I'd put it in a central Subversion repository and set up scripts (in Windows you could use the autorun feature for the USB stick) to synchronize things between the repo and a USB stick always carried along.
The main point I see reg. using SVN as central repository for binary files, is that if those files are of any reasonable size, they will take some time to be synced over the net.
So if you don't want to spend time waiting for your files coming in over the net, here the building blocks for an other mirroring solution:
MirrorFolder
No better tool to be found when it comes to syncing a Data-Tanks with
several other "local" copies.
TrueCrypt
Use this to encrypt your USB-Tank just in case you drop it somewhere.
FolderShare (http://foldershare.com) is also nice for syncing files. I use it to keep documents, etc. in sync between my laptop and my desktop, for example.
Of course, for code especially this doesn't obviate the need for source control.