I am looking for a 'local' source control software, I don't need it to be necessarily available on network.. Its meant to be only for personal use..
What I am looking for is something like:
Need it to be cross platform. The biggest problem is, I need the same local repository to be available on both windows and Linux! (Is this even possible? :s ) I dual boot Windows 7 and Ubuntu and have managed to setup workspace that works in both OS without changes, now I need a source control software!
Easy installation, I have never installed one before! :)
And Has eclipse plugin..
I have used VSS for this purpose before, but that is only on Windows!
I looked for Mercurial, but I am not sure if I can use the same repository on both the OS!
Any suggestions are appreciated!
UPDATE: Thanks for your replies.. Yes I do want the same repository to be accessed from different operating systems.. Everyone has suggested an on-line repository but I 'need it to be local'.. Internet is not something I can depend on (I now know git takes care of this..! :)), I would not want version of, say my personal recordings of some home functions tweaked in audacity, to be hosted on-line! Right now, I am trying out git, as a local repository solution..
If you definitely want a repository that's always available on a local filesystem, I'd probably go for Mercurial or Git. Most likely Mercurial, as it has the best windows support (including the TortoiseHg gui), but Git works similarly.
But there's two other issues:
Do you make frequent backups?
What file system type will you use for the shared repository?
In this particular case, I would not trust a single shared filesystem as the best basket to put your eggs in; In each boot environment, I would maintain working repositories separate from the shared one. This would give you some redundancy.
Here's how this would work:
Two repositories U and W, for Ubuntu and Windows respectively, and one shared repository S, accessable frome either boot environment.
Assuming a stable situation, with all three repositories in sync:
Commit any new code to repository U in Ubuntu.
$ hg commit -m 'changes from linux'
Push the changes to S.
$ hg push
Reboot into windows.
...
Pull the latest changesets from S into W
W> hg fetch
Update your code, commit frequently
Push prior to rebooting into linux
W> hg push
Reboot
And repeat step 4, but now from linux
$ hg fetch # performs an hg pull, followed by an update.
Rinse, lather, repeat.
That's said, with both Mercurial and Git, you can synchronise your repositories across the net any time, so I would surely recommend you try that out some time.
And note: the best backup is having a copy of your data on a live file system on another computer, preferably at another location.
I'm pretty sure you can Mercurial, since the whole repository is in .hg folder.
Try TortoiseHG - it's easy to install and use.
Why do you want it to be local? The benefit of source control, is that you can have multiple clients working on the same source, without worrying too much about conflicts etc.
Even though it doesn't really answer your question, this advices might solve your problem:
Just create a project for yourself at https://github.com/ or http://sourceforge.net/ any other free online repository hosting provider. SVN, CVS, GIT all come with excellent IDE integration and clients run on almost all operating systems.
Hope this helps. Regards.
Do you really want to have a duplicate repository on different operating systems? That doesn't make sense to me. What would be the purpose of doing that?
I think you instead want to have a single repository that you can access from any operating system.
In this case, you can just install Subversion (or whatever source control system you prefer) on a server and access it from the operating systems you use. There are plenty of client tools for Mac/Windows/Linux that can talk to subversion repositories, RapidSVN being free and cross-platform for one.
If you don't have your own server, there are plenty of places online that will host Subversion for you.
Related
Hi
I'm currently seeing a need for handling source code for a few projects I'm working on. I have no need for external hosting, but I do need to have a structure internal in my development environment.
So, how would you guys recommend to handle this? To you just place the files on a file share in your environment, or do you set up some kind of versioning systems? I'm quite new to this, but I would like to have some way of getting back to old versions of my code, I would like to have the source code centrally stored so I can reach if from bothmy laptop and workstation.
/Andy.l
Use a source control management system - I would suggest using a distributed one such as Git or Mercurial, so you don't need a server or need to be online to work.
You can still have a central location where you push and pull stuff from if you really want to.
If you must have a server, go with SVN - it is easy to setup and widely used.
With all of these options, there are hosted services that you can use as a central store.
If you are using windows OS, then Visual SVN is quite good. You can install it on the server and use a client like Tortoise SVN to connect to it from other machines. The basic version is free to use.
Definitely use a version control system, it will allow you to do some nice workflows on your coding day and have all securely stored. There are several good free vcs (git, mercurial, subversion, etc). For Some time I used a combination of git + dropbox or sugar sync to back up and share my repos
http://git-scm.com/
Do setup a source control repository. Using a SCM, has nothing but benefits.
With respect of what SCM system to chose, to very simple repositories to setup and learn are Mercurial (distributed), and Subversion (centralized). I know you said you wanted centralized access to your sources, but keep in mind that that doesn't meant you can't use Mercurial for that purpose.
Here's a great tutorial on Mercurial by Joel Spolsky.
Lots of choices based on environment, etc.
SVN is an excellent all-around choice for centralized source control. You can also use Mercurial and Git internally if you prefer DVCS (even in a local environment).
In any case, regardless of what version control system you have - get one. Even if it's just one developer doing personal projects, source control is a must.
There's no question that setting up a SCM makes sense and has only advantages. Which SCM to use depends on several circumstances:
Do your co-workers already know any SCM? We're using SVN and I think it would be quite hard to teach my colleagues the concepts of a DVCS like git
In my opinion, using a DVCS like git needs more discipline during work: you have to remember to push to the central repository.
But this is also an advantage: you can create your own development branches and work on them without publishing them to the rest of your colleagues (saves reputation in some cases :-))
If you or your co-workers often work from remote, using a DVCS is more comfortable than using a centralized one like SVN: you need no connection to your central repository but can still checkin, create branches and (quite important) view the complete history of your project without connecting (e.g. via VPN) to your servers at work.
For a centralized VCS, I can recommend SVN (setup as Hps supposed)
As DVCS I can recommend Git (msysgit with tortoisegit)
If you decide to use SVN, you can still use git-svn on the clients: the repository is being run with SVN, but anyhow, you get the advantages of a DVCS while being offline.
I have some general scripts that I use and they keep getting modified over time. Right now, I do not use any version control software for them so basically the old files are lost unless I explicitly save them.
I need a good minimal version control system that I can use on a single machine. Which one do you use for such projects?
Git or mercurial both work great. No server required.
I've used subversion for this in the past. Mostly this is because I'm in windows, and TortoiseSVN is a dead simple UI for my repo.
For a scenario like yours, which is relatively simple, I'd recommend using either what you're familiar with, or what is easy to use on your platform.
Git is actually really easy to use in such a setting, and it scales just as well to really small repositories with a few commits a month as it does to huge ones with a hundred a day. Here's how you would set up such a repository:
$ cd ~/your-scripts
$ git init
$ git add .
$ git commit -m 'Start script repository'
Ta-da!
As a hosting solution we make use of http://codesion.com/free_cvs_svn, you will note they also support Git hosting. They also host a bunch of other services that go hand in-in-hand with versioning.
Check out some of the personal version control systems. Hers is a short list:
FileHamster
History Explorer
FolderTrack
Oops! Backup
They are super easy to use and "automatically checkin" when ever you modify your files.
Note: I am the author of FolderTrack and recomend it for software because it can treat a bunch of files as 1 big project. Therefore if you need to revert your project to where it was yesterday, it will revert the 8, 10, or how ever many other files you modified since that time.
Free code: BOS
I have an online CVS repository that I need to check code into. However, the server is outside my control and is often down.
So, is there a way to set up some sort of local CVS server/proxy such that I can check my code into the local CVS server regularly and have the local CVS server batch commit the changes to the online CVS repo periodically?
The local repository could possibly run some other SCM system, if that was necessary to prevent conflict with CVS. Online commits could possibly be done manually, or via cron. I'm open to suggestions.
I guess that my main concern would be the problems faced in trying to set up some sort of repository 'hierarchy'.
PS: I'm running Linux all along the 'hierarchy'.
Edit: Found a similar item here.
Use git locally, and then git-cvsexportcommit would be my suggestion. There's a blog post that talks about this at http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html although I'll be the first to admit that the export process isn't as easy to use as perhaps it could be.
I'd recommend running git locally while continuing to use your CVS server when you have a connection to it. Here's a nicely-written article that explains how:
http://www.kernel.org/pub/software/scm/git/docs/v1.4.4.4/cvs-migration.html
You can use git as a "frontend" to CVS which will allow to you check-in your changes locally (offline) and then sync them up to the CVS server when your connection is available. There is a bit of a task to setup the environment, but once you get it going the workflow is pretty nice.
See How to export revision history from mercurial or git to cvs? for the setup & workflow.
This doesn't really answer the question, but it sounds like you need a distributed VCS system.
I think you should consider using a distributed source management system such as git or mercurial which support this kind of decentralized source control.
I have never used it, but CVSup may do what you need. As others have mentioned, though, a distributed VCS system like git or mercurial would probably be better.
Can anyone recommend a good Source Code control (SCC) that works for the mostly disconnected consultant? I'd prefer something that allows one to save into a local repository and then once connected 'syncs' to the server however I've never seen such a feature. Suggestions? [Windows solution is preferred that integrates with standard IDEs the SCCI API].
Any distributed version control service is going to do that. Check out Mercurial or Git.
You may want to look at git.
It lets you commit things locally, and then resync back to another copy. Its very decentralized and it appears to work in windows.
Git may be a good alternative in this case.
From wikipedia: "Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. "
http://git.or.cz/
Assuming you're working with Windows, I'd suggest syncing a local folder using TortoiseSVN on the client side (http://tortoisesvn.tigris.org/) to a VisualSVN Server-based repository on the server side (http://www.visualsvn.com/).
All available free.
If you want a full up local repository, it sounds like you might want to look at Mercurial. I haven't used it other than a quick look-see, but it looks very interesting and powerful, and to the best of my knowledge provides a distributed source control process that replicates the repository allowing a disconnected user to still access things that they didn't "checkout" while connected.
For Windows you'll be better off with Mercurial. Especially if you're familiar with Subversion.
Git may be the closet thing to get to what you want.
Bazaar supports this workflow. It is also do able in git, but it's more intuitive in bzr, imho.
Sorry doesnt solve your want to have it merge to multiple repositories but SVN + TortoiseSVN on windows is a good combination. There are also Visual Studio plug ins for SVN if you use VS.
If you need a third party SVN provider i use SVNRepository.com
You need a distributed source code control.
Wikipedia has a good comparison table of source code controls. I'd say pick the distributed source code control that best suits your needs.
You can do this with most systems(cvs, svn, git, and so on).
As for an application that will automatically sync when connected; I would not recommend this. It is better to commit intentionally. Depending on how you use a repository auto check in could break an active copy in your repository, or pass in code that hasn't been tested yet.
A decent client for subversion in windows is TortoiseSVN. http://tortoisesvn.net/
If like GUIs, then check plastic. It works both disconnected (well, actually distributed, using your own server at your laptop) and centralized
My office has a central Source Safe 2005 install that we use for source control. I can't change what the office uses on the server.
I develop on a laptop and would like to have a different local source control repository that can sync with the central server (when available) regardless of the what that central provider is. The reason for the request is so I can maintain a local stable branch/build for client presentations while continuing to develop without having to jump through flaming hoops. Also, as a consultant, my clients may request that I use their source control provider and flexibility here would make life easier.
Can any of the existing distributed source control clients handle that?
Well... KernelTrap has something on this. Looks like you can use vss2svn to pipe the Source Safe repo into a Subversion repository, then use the very nice git-svn to pull into a local git repo.
I would assume the commits back to VSS would not be a smooth, automatic process using this method.
You should be able to check out the current version of the code and then create a git repository around it. Updating that and committing it to your local git repository should be painless. As should cloning it.
The only catch is that you need to have them both ignore each other (I've done something similar with SVN) by messing with the appropriate ignore files. I'm presuming SourceSafe let's you ignore things. And you'll need to do certain operations twice (like telling both that you are deleting a file).
This episode of HanselMinutes covers exactly what I was hoping to hear. Apparently Git can be used locally then attached to external subversion/vss repositories as need. They talk about it 14 ~ 15 minutes in.
some day I work in a company that use VSS (and in other companies that use other less unknow SCM) but i prefer use SVN (someday I'll try GIT) for active development, for me and my group.
First of all, this situation it's only good idea, if commit to VSS are few over month, because working with other SCM (than VSS) give you more flexibility, but commint to VSS from SVN is expensive in time.
My solution was:
VSS -> SVN: I have linux script (or ant script, or XXX script) that copy from currrent update directory work of VSS to current SVN, then refresh SVN client and update/merge/commit to SVN. With this, you are update from changes of the rest of company that use VSS.
SVN -> VSS: In this way, you need a checkout of all your modify files to VSS, then you can simply use the reverse script to copy from current update SVN directory (ignore .svn directories) and copy to current update VSS directory, update and commit.
But remember, in a few case does worth your time to do this.