Here is the scenario that I have. I have a cvs repository in one location (A) and I want to replicate it and keep it in sync with a repository in another location(B). This would be a single directional sync from A to B. What is the best way to do this? If it is not really feasible in CVS then which source code control system would you recommend to accomplish this? Thanks
When using CVS, I don't know any tools to do that other than files syncing. You can achieve that using tools like rsync (Unix) or xcopy/robocopy (Windows).
If you plan on migrating to Subversion, it provides a tool called svnsync that allows to sync a repository from another one.
I would recommend you migrate from CVS to a proper distributed version control system such as git, which will provide this sort of functionality very naturally.
Subversion also provides svnsync which does the same sort of thing.
If you do take the rsync/filecopy approach with CVS, it is important to only sync the files at a time when there is not an active commit. Otherwise, the repository's lock file will get copied over and you will be unable to checkout/update on the target side until the next sync.
This reason alone may make CVS a bad choice. The migration path from CVS to Subversion is pretty smooth and there are tools to import a full CVS repo, with history, into Subversion.
Consider Git or Mercurial if you want to get into true distributed versioning, but it sounds like that would be overkill for your "read only" needs.
The Best (and perhaps costliest) way is Clearcase Multisite
But if you are looking for opensource, Git is becoming quickly replacing svn everywhere..
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 just begun working on a project which uses Mercurial as a version control system, and I need some basic tips on how to use this. Please use this question to give some introductory tips on this technology.
The official Mercurial site
Especially, I am looking for tips on the best programs to use and the best techniques to use (branches, in and out-checking etc. I need to learn the best-practices!)
I know you already have the Mercurial site but the resource most useful to me was the Mercurial book. It's an excellent overview of the program and how to use it.
I found the best way to learn Mercurial was just to use it on a project. I imported into Mercurial a project I had exported from subversion and did some regular development with it. I made sure to clone the repository for different changesets so that I could get used to the merging and updating. I haven't learned all of the advanced uses but I'm now on a pretty firm footing with it and haven't switched back to Subversion yet.
A lot of projects have different techniques for commit workflow. Some have changes pushed from the developers, like centralized systems, and some will pull the changes from contributors (Linux, for example). It's hard to generalize too much without knowing the process for your project.
This is how I do my development:
Centralized tree on a file share or http, called project-trunk or project that is the definitive project version
A clean tree on my system that I clone from the remote repository and use to push back to the repository. I then clone from this tree for my changes. I call this tree project-local
Clone the project-local tree for each of my changes: eg. project-addusers, project-141, etc.
After I am finished with the commits to a tree, I then push the changes to the project-local repository
Finally, push the changes in the project-local to project-trunk
I have the clean project-local tree because then I can push all the changesets back to the trunk at one time, which is helpful if there is a group of related changes that need to push back together.
As for tools, it depends on your platform. I just use the vanilla command line tool. Coming from TortoiseSVN, it was a bit of a change to go to the command line. But I'm fine with it now. I tried using TortoiseHg but it didn't function well on my Windows 7 x64 virtual machine. I hear it's much better on the supported 32-bit platforms.
Here is a helpful tutorial on Mercurial written by Joel Spolsky.
It covers basic usage and commands, as well as how to work with Mercurial at a more conceptual level. If you are already familiar with SVN, then the first part is definitely worth reading: it talks about the major conceptual differences between SVN and Mercurial, because trying to use Mercurial in the same way that you use SVN is asking for trouble.
Have a look at the Mercurial book, or at this Mercurial tutorial.
Depending on your background with other source control tools, I would also suggest a specific SCM-whatever to Mercurial guide. For example, have a look at this guide for Subversion users.
Another good resource for getting your head around the whole "distributed" source control idea is: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ ... with helpful diagrams!
If you use the latest TortoiseHG client and include the install directory in your PATH environment, you will be able to use both the nice GUI they provide, and the command line 'hg'
I cannot recommend using the mq extensions too much. They make for a great 'working repository' environment.
I use the queues to manage local changes against a subversion repository. I do my local short term changes and use mercurial to keep in sync with subversion and the rest of the team.
A few of Steve Losh's blog posts are good, even though they're a couple of year old now. They mainly deal with how to work with branching.
Guide to Branching in Mercurial
Branch Workflows - Branching as needed
Branch Workflows - Stable and Default
It's also worth looking at his hgtip.com site.
In addition to the Mercurial Book and the Hg Init tutorial, I'll like to mention the example-driven guide I've written:
Mercurial Kick Start
It shows how to get started with Mercurial and also covers some more advanced concepts such as named branches and hgsubversion. I've used it when teaching Mercurial to new users and they seemed to like it.
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.