CODEWITHSUNDEEP
svnversion-controltortoisesvn
radarbob
radarbob

Reputation: 5101

Create External SVN Repository of Files Sourced in Another SVN Repository

I have a working copy of the original subversion repo. I want to make experimental changes to the certain files in the working copy without branching, tagging, etc. in the original repo.

Goals

The Details are the Devil

I am aware of the external property. I think this is the key, but I must be misusing the tortoise interface because I cant get things to work out.

Please do not

Upvotes: 0

Views: 833

Answers (1)

David W.
David W.

Reputation: 107090

Let's look at what you want. I'm going to number them so I can refer to them later...

  1. To be able to readily point back to the original at will.
  2. There is no intention of ever merging the changes back to the original repo trunk.
  3. capture many discrete "experiments", capture as little code as necessary and keep it all out of the original repo.
  4. Synching with particular original repo versions is unnecessary.
  5. I want to be able to start with a working copy of the original repo and target particular folders and/or files to go into the experimental repo.

According to #2, you will never merge this code into the original. That's fine. You can have branches and never do anything with them. According to Point #4, you don't even want to sync back to the original repo. Once you have your changes, you won't want newer stuff from the repo.

Point #1 and Point #3 confuse me. What do you mean to be able to readily point back to the original at will? Do you mean changes in the original repo needs to be put in yours if necessary? And, what do you mean by many discrete experiments? Do you mean that you want to try different directions from the original changes?

What is preventing you from checking out your base code, and simply creating your own private repository?

You could use branches for your many discrete experiments by simply branching again and again from the original code base which you'd mark by creating a tag. You could get back to the original at will by simply going back to the tag.

Would that work?

$ # First create the experimental repo
$ cd $HOME/my_repo
$ svnadmin create my_repo
$ # Now let's start it up
$ svnserve -r . -d
$ # Now, let's do a checkout and get some work done!
$ mkdir $HOME/my_workspace
$ cd $HOME/my_workspace
$ svn co svn://localhost my_project
$ cd my_project
$ # This is an empty directory. Let's fill it up!
$ svn mkdir trunk tags, branches
$ cd truck
$ # Now, get the revision you want and put it in your repository
$ svn export http://server.com/src/trunk/project .
$ # We have all of the code, let's add it to our repository
$ svn add *
$ cd ..
$ svn commit -m"Original code"   #This is  your original
$ # Now, we'll mark the original, so you can get back to it
$ svn cp -m"Tagging original" svn://localhost/trunk svn://localhost/tags/ORIGINAL

Now, you have your own repository, so your changes won't show up in the original repository. And, you can go back to your original source by looking for the ORIGINAL tag.

Let's do three experiments

$ svn cp -m"Experiment #1" svn://localhost/tags/ORIGINAL svn://localhost/branches/experiment_1
$ svn cp -m"Experiment #2" svn://localhost/tags/ORIGINAL svn://localhost/branches/experiment_2
$ svn cp -m"Experiment #3" svn://localhost/tags/ORIGINAL svn://localhost/branches/experiment_3

Notice how I branched from my ORIGINAL tag? That way, I know I'm back to my original code. Notice that branches are used for each experiment. I may never merge in-between them, but that's fine. Nothing says you ever have to merge from one branch to the next.

And, you can always delete branches once you've finished with the experiment:

$ svn delete svn://localhost/branches/experiment_1

This is still in the repository, but you'll no longer see it when doing an svn ls on the HEAD. However, it is still accessible if need be. It keeps clutter out of branches, but still makes it available if you ever need it again.

So, don't worry about externals, simply create a new repository, import your code, and have fun.

However, when someone wants to do something like this on my system, I'll usually discourage it, and give them a branch they can play with on the original repository. For example, I might give bob a directory called /branches/BOB/trunk, branches/BOB/branches branches/BOB/tags. This way, it's marked that this is Bob's private area, and he can play around and do whatever he wants. At the same time, Bob can grab code over and over again from the repo, and even capture newer code. If a lot of people want to do this, I'll add a private folder to the initial hierarchy:

/trunk
/branches
/tags
/private

And give each user their own directory under /private. I have a pre-commit hook that can prevent users from touching other user's code. By keeping everything in the repository, we have more flexibility. Users can share code, take different revisions, and play around. I've never had a problem with keeping private experiments in the main repository.

Upvotes: 2

Related Questions