I have remote svn repository. I want to check-out it (with history) and then use in Visual Studio as regular repository. After a while I will submit (commit changes) from local repository to remote repository (and also update files if any).
So it seems I just need two copies of svn repository and I need ability to synchronize them.
How to do that?
That goes against what SVN is. What it sounds like you want is a DVCS like Git or Mercurial, hence why many developers have moved to something like that.
I would use git; and use the git-svn bridge to be able to communicate back to your SVN server.
Git keeps a full copy of the repository when you clone from SVN (which means the initial clone can take a long time since it needs to checkout every single revision). You would then commit locally to your Git repository; and dcommit (push) back to your SVN repository.
I don't know of any clean ways to do this using SVN alone. A typical workflow might be:
git svn clone http://yoursvnserver/svn --username vcsjones
#make some changes
git add -A
#stage your changes. add -A stages all changes;
#you can stage individial files too or use git add -i for interactive adding
git commit -m "My commit messages"
#repeat makes changes and commit as many times as you want
git svn dcommit
#commit all local commits back to the SVN repository.
If you are a one man shop; keep your repository on a USB flash drive (and just make sure it gets backed up somehow incase you lose it; it becomes faulty).
pull & push examples –
Squib As other answers have stated, you can not have 2 SVN repo with bidirectional sync. For SVN-SVN pair you can build only one-way sync RO SVN-mirror.
For a local repo that can exchange with central, you must use DVCS. There is no way to do it with straight SVN, not using an auxiliary DVCS. If you don't want Git, you can use Mercurial with hgsubversion, Bazaar... but anyway it's additional SCM.
For solo-work (if you really have to work this way) it would be better to branch on the server. Just don't forget to regularly merge trunk to your branch; this will help you avoid a "merge headache."
As vsjones answered, you can use git-svn to checkout a Subversion repository, use it as a local Git repository, and then post back up to it. You can even use the Microsoft Git Source Control Provider to allow you to integrate Git with VisualStudio.
HOWEVER, I would like to ask you why you want to do this. It appears that you could be what we in CM parlance call Crawling into Your Cave.
Crawling into Your Cave means that instead of working with everyone else, you're going to do your work in private without any oversight. You want to get your code to be absolutely perfect. You want a masterpiece of computer code. Then, you're going to unveil it to the unsuspecting world that will be wowed by your coding skills. You'll be hailed a genius and maybe even get a chance to talk to a girl.
Of course, the problem is that coding always works out best when it is in public view. Code reviews aren't just for completed code. It's also for code while it is being written. Before you go too far down a blind trail.
Another issue is a tendency for developers to bite off more than they can chew. If I need to check in my work on the same trunk as everyone else, I am more likely to take smaller bites of code. (Yes I could have made a pun on bytes, but I'm trying to be serious). I'll make a change, maybe add a few methods, test and commit. Then, do more changes, test and commit.
I use to be a ClearCase administrator. In ClearCase, each developer gets their own development stream. You code on your stream, then merge your work into the integration stream. (Basically, everyone got their own branch, and you merged your changes into trunk). As part of my job, I would hassle developers to check in their changes. I ran reports looking at the last time a developer delivered code. I constantly had to handle merge issues. I felt like a cop on a beat.
Then, I had a job where everyone used CVS. In CVS, branching is a pain, so everyone worked on the same branch. I couldn't imagine how this would work. How can three dozen developers work all on the same branch? Yet, over time, I started to realize that not only could everyone work on the same branch, but there were fewer problems. I no longer was the beat cop, and instead of making sure all the developers followed the rules, I could do other CM functions that I never had time to do. My relationship with the developers changed. I was no longer the guy who came around and told them what to do. Instead, I was someone who could help.
So, be careful about doing your work in your own private repository and then delivering the finished product to your team. If you are doing major work that will require long term development that might break the build while you're doing it, ask for your own feature branch in Subversion. That way, everyone will see what you're up to.
This isn't to say there isn't a legitimate reason for using git svn. I personally like checking in my code every few minutes. This gives me the ability to revert a file as it was five or ten minutes before I started making a mess. I still take small bites, and I check in my code when I'm done. I'll average about 3 to 4 commits per day to our main repository. I too use svn git, but not so I can crawl into my cave, but so I have a life rope that I can use to pull me out of a messy coding situation.
So, take a look at git svn, but please don't use the excuse that you have your own repository to hide away from the rest of your group. You can use the MS Git Provider (or the [SVN provider from AnkhSVN).
There is a way to clone an SVN repository to a different SVN site with all or partial history. It is as easy as running the command below in bash.
clone-svn2svn.sh <source_svn_url> <destination_svn_url>
I spent quite some time to achieve that goal and wrote a script so it is automated and documented for others. The script uses git behind the scene but it abstracts git away from the user (unless something goes wrong of course).
GitHub: clone-svn2svn
There are also instructions on how to update the repository from the source after it was cloned. You can find them on the GitHub page. Unfortunately, I didn't write a script for that and you need to get your hands dirty with git command line. It can also be automated.
You create a local copy of the latest repository revision via
svn checkout svn://host/repos/test folder
If you need the whole history, it is required to clone the full server repository with tools like svnsync or git svn (the latter was described above).
If you use svnsync for creating a repo copy, don't be confused that the cloned repo does not contain your committed files. That's because the SVN server keeps the files in the FSFS format in the db/revs/ folder. You'll be able to retrieve the files via the usual svn checkout file:///path-to/SVNRepository/ folder way.
© 2022 - 2024 — McMap. All rights reserved.