Very similar to this question: Sync two files, but using svn instead. Is there any way other than using a symlink or adding a step to the build? I was hoping for svn modules, or svn copy, but if it's really impossible, I don't want to spend a lot of time on it. This is a Linux based environment.
You can use svn externals, but the purpose of externals is not to clone individual files in the same repository. You might find it a little bit slow and clumsy for this purpose.
Related
I am using a commercial Subversion hosting service. In order to make a copy of the entire repository, I can make a request. This gets put into a queue, which normally takes hours. In addition, I have several (10s of) projects hosted there. Each copy request has to be separately for each project, which is kind of painful if I want to do this on a regular basis.
So, is there a way I can make an exact copy of the archive from a Linux command line? i.e., just with the SVN client installed?
Or is there any easy (preferably scriptable) way to obtain an archive copy of my repositories?
Kind Regards,
Madeleine.
Take a look at the tool rsvndump. It looks like it'll do what you want.
For Subversion version 1.7 or later, there is the command: svnrdump which worked for me.
Syntax:
svnrdump dump https://yourRepository/yourProject > yourProject.dump
I want to add my project to a subversion repository. The project folder contains a symlink to a folder containing thousands of txt files that I don't need to add to the svn repository. I DO want the symlink-folder to show up when I checkout the code, however.
It looks like I can use svn addprop svn:ignore symlinked-folder to ignore the folder, but then I'll have to add that symlinked folder to every working copy I check out before everything will work.
Is there a proper way to do this?
Perhaps there is no way to deal with this, since a symlink is a filesystem artifact. Is there a better way to handle this situation?
CONCLUSION - EDIT
After all this investigation, I committed the symlink-folder by accident and SVN added it to the repository without adding any of the files within it. Upon checkout, everything works fine. The symlink-folder checked out and works.
I am using assembla to manage my SVN repository, so that might have something to do with this success.
The answers above are right, your symlink won't work if you check out the repository on windows.
But if you're aware of that and you don't care, you can add just the symlink without its contents:
svn add -N your-symlink
man svn add here
I believe you are correct, imagine if a user checked out your repo under Windows - how would SVN create the symlink when the underlying OS doesn't support it?
Is the target folder that you are symlinking to under version control? If so, you can make use of the svn-externals property.
You are right, it doesn't make sense to add a symlink to a repository. What would happen if someone checked out the source on a machine that didn't have access to the folder the symlink points to?
One way is to structure your repository so that you can check out the codebase without having to check out documents. E.g.:
Trunk
Tags
Branches
Documents
So you only check out the trunk or branch that you are working on, and when you require it you can check out the documents.
Alternatively, use a project management tool like Redmine to store your docs. It can integrate with svn as well so you can view your repository and manage permissions through it.
This is maybe unusual so let me set the scene:
We have an SVN repo containing our project history - an embedded system based on Linux. The SVN repo contains Linux kernel, U-Boot, busybox etc. sources and all our in-house apps, filesystem and such.
The Linux kernel we have is old and crusty and I am working on porting to the mainline, which is under active development for our platform(s). I am doing the kernel-side work under git and trading patches with "The Community".
I could get things working and take a snapshot of the kernel sources and dump it into SVN, but I'd like to keep the ability to get updates, have local branches and manage patches with git. I could keep two copies of the kernel, one managed by each SCM, but that would be a bit messy. There are also risks of developing and testing using kernel sources managed under git, and forgetting to put those changes into SVN resulting in broken SVN versions where the non-kernel sources are out of sync.
Migrating the entire project to git isn't an option. Managing just the kernel source with git and having a bunch of glue scripts and stored hashes in SVN is possible but it's nicer to have a unified history / diffing ability from SVN for the whole project.
What I'm considering is trying to manage the kernel sources under both SVN and git simultaneously, in the same directory.
As a kernel dev I'd mostly use git and do an SVN commit for internal use when things look good. For other internal users they would be able to get the entire, consistent sources with one SVN checkout, see a unified history, and they could make changes to the kernel sources under SVN. Later I or another git-using person can SVN update to those changes and commit them to git as appropriate.
Some funning around getting git to ignore .svn files and vice versa will have to be done. Also I'm not quite sure how one would take a plain SVN checkout and tell git to start managing the kernel subtree as well, but I'm sure git has some obscure swiss-army-knife options to do it.
So that's my idea du jour. It means most co-workers don't have to worry about git, and we can quietly ignore git and fork away later as needed.
The question here really is, has anyone done something like this, how did it work out, or what alternate solutions did you come up with?
I've done this regularly, and it works great.
The only major thing I needed to do was add the .git folder to the subversion ignore list, and the .svn/ folders to the .gitignore file.
RSync is traditionally used to update Gentoo portage tree.
But it's somewhat slow when dealing with a large number of files.
So, I want to try to replace RSync with Git.
I know that Funtoo have Git-based portage tree, but is there a Gentoo-specific official one?
As a Gentoo developer I can say that there is no official git repository for the portage tree. There are plans to switch from what is currently used, CVS, to git, but that may still take a while.
Currently, there are three ways to get the tree:
Via rsync, as you mentioned.
Via CVS, commands for anonymous access and online browsing can be found here. Updating is done with cvs update which is probably slower than rsync.
By downloading a tarball of a portage snapshot from your nearest mirror, generated daily.
All other ways aren't official (such as the funtoo git repository mentioned in another answer), although they may be what you're looking for.
Funtoo has not only it's own Funtoo portage tree via Git, but they also keep a plain Gentoo portage tree via Git, as well. You can configure Funtoo to use the Gentoo branch, and then you basically have an "official" Gentoo portage tree via Git.
As of 9th Aug, 2015, Gentoo has migrated their portage history to Git. You can check it at:
https://gitweb.gentoo.org/repo/gentoo.git
Or clone it at:
https://anongit.gentoo.org/git/repo/gentoo.git
However, there are a few things to point out:
The repository does not include any commits before the migration. A "git replace --graft" is proposed [1].
The Git portage tree does not contain metadata cache. You might need to generate by yourself using egencache or "emerge --regen".
The Git portage tree does not contain any news or GLSA information. They are stored at:
https://anongit.gentoo.org/git/data/dtd.git
https://anongit.gentoo.org/git/data/gentoo-news.git
https://anongit.gentoo.org/git/data/glsa.git
[1] https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration
For anyone interested in it nowadays: it comes out that after one of latest portage updates (2.2.16) it's possible to change to https://github.com/gentoo/gentoo-portage-rsync-mirror.
Another Gentoo dev here, and pretty much just seconding spatz' comments. Rsync is actually faster than you might realize, as a large git tree can take a while to sync. Have you tried forcing Portage to use a different rsync mirror? Some mirrors can be slower than others. There's been spots where I found a European mirror to be better than a US mirror. YMMV.
See the gentoo-scm list for up to date information on the git migration of portage: http://archives.gentoo.org/gentoo-scm/msg_57eaa893711e1b63faa4502e8921376b.xml
Short: Not yet, but they are working on switching to git.
Difference to funtoo: The tree will have the whole cvs history.
Agree to dev that rsync is stil faster.
On addition, if you think http download is faster, most Gentoo mirror maintain a portage snapshot for http/ftp download.
Use emerge-webrsync to download or just discover the url matching your current mirror setting in make.conf. Once you get the url, you can use sth fast on http like aria2. Which might fetch files from more than one url.
From what I can see, the Gentoo repository doesn't come with a (D)VCS repo.
The only exception being this godin-gentoo-repository, which is actually only his copy of my local overlay/repository.
So that leave you with a list of Git repos hosting to chose from, and an initial import of a rsync of that tree in your very own Git repo.
The update process would still be slow (rsynch + git add -A + git commit -m) for you, but would be a lot quicker for your Git Gentoo repo followers ;)
I have 3 Linux machines, and want some way to keep the dotfiles in their home directories in sync. Some files, like .vimrc, are the same across all 3 machines, and some are unique to each machine.
I've used SVN before, but all the buzz about DVCSs makes me think I should try one - is there a particular one that would work best with this? Or should I stick with SVN?
I've had this problem for years, and I don't think version control is necessarily the right way to go. I've had good success with the the Unison file synchronizer which is designed for the express purpose of maintaining consistent home directories on two machines. I'm currently managing seven replicas with unison, and the details are a bit tricky, but it is a great tool and if you start with two you will be extremely pleased.
The key difference between Unison and a VCS is that Unison is willing to delay dealing with conflicts that have to be merged. Plus it gets all the defaults right. And it is fast: I use it daily, over a DSL line, to synchronize about 40GB of data.
Any DVCS would likely work fine. My favorite is Bazaar. It would be easiest to keep your config files in .config, version that, and then symlink as appropriate.
A benefit of DVCS is that you can version the per-machine config files as well, without interfering with versioning global configs.
I've had the same problem, and built a tool on top of Subversion that adds permission, ownership and secontext tracking, keeps the .svn directories out of the actually versioned trees, and adds a concept of layers so you can for example track all your config related to development, which you then only check out on machines you use for developing.
This has helped me organize my settings much better across the 50+ machines I log into.
Here's the project page. It's still a little rough around the edges, but we also use it at work to version system configuration for our 60+ servers.
In general, any version control system that uses some sort of metadata files to track stuff is going to cause you pain as is when actually using it.
Version control software isn't really great for home directories. Worse, some software doesn't really like the .svn folders or starts to interpret their contents. You could of course try to fix this with some very complex mirroring setup, but that's hard.
Here's a Mozilla developer that's tried to do this: Version controlling my home dir, there's a couple of suggestions in the comments.
git or Mercurials's cheap branching would work great for this situation. I started with Mercurial, because it is simpler, but have subsequently moved to git.
One way to handle this very flexibly is to have a build directory under revision control, not try and svn your actual home directory (which has its own issues)
so inside this you keep a structure like
/home/you/code/dotfiles
/home/you/code/dotfiles/dotbashrc
/home/you/code/dotfiles/dotemacs
...
/home/you/code/dotfiles/makefile
and the makefile can contain logic for specializing files (or not)
might be heavier than you need, but if your actual setup is complex (I've done this across 3 or 4 different unices at a time) then it's worth doing something like this.
I use git for this. So far, I have been able to keep the home directories on several machines synchronized, with no need for branching and merging. Instead, I use git rebase. Conflicts so far have been few and far between and easy to resolve.
I keep files that need to have separate contents out of revision control by putting them into .gitignore.
I keep configuration files for the following tools in git:
various shells
emacs and applications, i.e.
gnus
BBDB
emacs-w3m
mutt
screen
various utilities and scripts
I keep notes and such in a subdirectory which has its own git repository.
I would suggest looking into etckeeper if you haven't already. It's designed for versioning configuration files in /etc using a version control system:
etckeeper is a collection of tools to
let /etc be stored in a git,
mercurial, darcs, or bzr repository.
It hooks into apt (and other package
managers including yum and pacman-g2)
to automatically commit changes made
to /etc during package upgrades. It
tracks file metadata that revison
control systems do not normally
support, but that is important for
/etc, such as the permissions of
/etc/shadow. It's quite modular and
configurable, while also being simple
to use if you understand the basics of
working with revision control.
Although it's designed for /etc I think it would probably also work well (perhaps with some adaptation) for home directories since the basic needs are the same.
I know this is an old thread but found it while searching for some dotfiles.
My current system is using subversion. The key thing I did was check out the working copy into ~/.svnhome/ (in hindsight should have called it .dotfiles or something more generic). I then create symlinks to the files I actual use on that computer into home. For example my .procmail and .spamassassin folders are only needed on the mail server so I don't link those on my home server.
The only file that has some differences is the .bashrc file has some extra lines on my mac for macports. So at the bottom of .bashrc I have it check if .bashrc_local exists and parses that.
This is the last remaining thing I have using subversion (everything else is using git aside from work). The benefit of svn is because it's not a dvcs so I don't have to worry about accidentally committing on one server and forgetting to push it.
I have considered moving it to git so I could create branches. Using the above example I would have a branch for my main server that I would add the .procmail and .spamassassin folders but not have those in the master branch. But the current system has worked fine for years--before git even existed--and don't have any particular motivation to change it now.