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.
Related
The company I work for uses Clearcase, even though it was EOL'd on the platforms in which we run it years ago. It is ancient and fragile tech, but one thing it does have is a multisite support that allows for the synchronization of air-gapped repos. Because of security issues, we use secure USB sticks to copy packets and take them to the other side, then apply them with scripts.
Developers and DevOps people want to make a business case to migrate to GitLab, but I cannot find any mention of a feature in GitLab that would allow me to do easily do this. There's something about bundles, but the info I have found is years old and it doesn't seem like too many people are using it.
Does GitLab not support this? Simple synchronization of one repo to another over an air gap using some sort of secure media? If so, it's no wonder so many teams are still using ClearCase.
While not exactly easy, air-gap updates of Git repository is possible through the git bundle command.
It produces one file (with all the history, or only the latest commits for an incremental update), that you can:
copy and distribute easily (it is just one file after all)
clone or pull from(!)
This is not tied to GitLab, and can be applied to any Git repository.
From there, I have written before on migration from ClearCase to Git, and I usually:
do not import the full history, only major labels or UCM baselines
split VObs per project, each project being one Git repository
revisit what was versioned in Vobs: some large files/binaries might need to be .gitignore'd in the new Git repository.
You would not "migrate views": they are just workspace (be it static or dynamic). A simple clone of a repository is enough to recreate such a workspace (static here).
I have a PC where I have both a Linux and a windows installation. I use a cloud service so I have access to my important files in both places, and they are synced.
Say I created a git repository, and pushed it to GitHub on windows. Now I suddenly feel the need to switch to my Linux installation to do some stuff. My cloud service does not sync the .git folder, since it's hidden in default by windows. (Would it lead to problems between os'es if i would sync it?). Therefore, Even though I have the same project (with exactly the same files) as on windows, Linux does not automatically recognize the VCS settings of the current project.
I found a somewhat dirty workaround, on Linux I
Initialize an empty rep: git init
Add a remote branch:git remote add Project_name https://github.com/Psychotechnopath/Project_name.git
Fetch the contents of the remote branch git fetch --all
Reset the head onto the remote master branch git reset --hard Project_name/master
Is this the best way to do it (e.g. respecting the git workflow), or are there more elegant ways?
I have mostly-successfully done this on the same filesystem; in my case I mounted the ntfs filesystem from Linux. Two things you have to be careful of:
don't make filenames that are the same on a case-insensitive file system but different on a case-sensitive one
pay special attention to your line endings, you may need to do some work in .gitattributes here
push often in case you find a git bug
If you don't mind having the world's slowest Linux system, you can also just run Linux under Windows via Window Services for Linux, WSL. (Not WSL 2, that's containers). In that case, you can access your windows repo from linux via the /mnt/c/ filesystem.
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.
I just logged onto http://www.ezsvn.com, that hosts my SVN repository. I have been paying monthly for hundreds of commits.
They're shutting down, and their support is nonexistent.
Can I get a backup of my repository from my machine? I’m using Windows.
If you have shell access:
http://wiki.archlinux.org/index.php/Subversion_backup_and_restore
If you don't have shell access (look at both the original answer and also the comments re: svnsync):
http://moelhave.dk/2006/07/remote-mirroring-a-subversion-svn-repository/
If you have access to run svnadmin on their server, it'll be no problem, and I see Dav has already linked to instructions for that.
Now, if you don't have access to run svnadmin, as far as I know it's not possible to use the SVN client itself (maybe TortoiseSVN for you) to copy the entire repository. (EDIT: never mind, I guess that was wrong. I'll leave the git info here just for the fun of it though.) But you can convert a whole Subversion repository to git, and here are instructions for doing that: http://pauldowman.com/2008/07/26/how-to-convert-from-subversion-to-git/ From there, you might be able to convert the git repository back into an SVN repository on another server. I know it's not really the answer you were looking for but if nothing else works, it will at least let you save your project's history in some form. (And hey, you could take it as an excuse to switch to distributed version control, which is all the rage these days)
If you really want/need the full history of your repository, you'll have to either get a dumpfile from the provider or get it yourself - some of the responses so far have addressed this already.
Another option: if you are not concerned with past revisions, but want your repo at it's latest state, just checkout the head revision, and export it to a separate location on your computer. That way, you have all your work to this point. You could then keep that as a backup, or possibly create an SVN account elsewhere, and import the exported copy into a fresh repo, then you would be back in business.
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.