0

I have access to a read-only SVN repository of a certain project.

I want to extent this project with my own modifications/additions. If I had full access to this repo, i could simply make my own development branch. However, I have not (and won't get write access).

I would like to have my modifications stored in an (internal) repository so I can keep track of my own developments.

Is it possible to set up a construction using SVN that can deal with this?

Initially I was thinking about creating an (internal) SVN repository with a the structure as below:

  • trunk

    • containing a copy of the external repo making use of svn:externals

  • branch

    • my development branch based upon the trunk

However, I quickly found out that it is not straightforward (if not impossible?) to create a branch based upon an 'external' folder. I also want to be able to merge changes in the external repository into my own development branch. I also doubt whether this is possible using this construction.

Is it possible to get this construction working? Or should I deal with this in a completely different way? Any advice on this issue is greatly appreciated.

thanks

peter

peter
  • 1

3 Answers3

1

You made small mistake in the are "Who Where"

  • You have vendor branch (svn:external) without peg-revision
  • Your own development happens in trunk (initally created as svn copy of vendor-branch)

From time to time you merge from branch (vendor-branch) to trunk

This method have some limitations for big and complex upstream-projects, but works on small|mid-sizes

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
-1

Is it possible to set up a construction using SVN that can deal with this?

Yes, you can. As one of the options, it is possible to duplicate remote repository using svnsync. But I wouldn't recommend doing this because you will get into trouble when will try to merge changes in your local repository and remote repository.

It seems that your case is perfect for using git-svn. It will allow to use your local repository for your own modifications/additions. The thing is that you will be able to keep track of your own developments using local git repo (doing pushes and pulls) and get changes (doing update) from remote svn repo when you need it. But, of course, you still will not be able to commit to the remote svn repo because it has read-only access.

Here is a short tutorial on git-svn.

altern
  • 5,829
  • 5
  • 44
  • 72
  • Why use chicken to simulate beef with chicken-beef, when beef is available standalone? – Edwin Buck Feb 16 '12 at 19:51
  • @LazyBadger: You sound a little bit offensive. For your information, I'm not a git-boy. Actually, I love `svn` and (if you even manage to try to look into other users profile) all my answers are mostly about `svn`. But particularly in this case I think `git-svn` is an appropriate choice. That's very rare case I would recommend git instead of svn. I understand your concern about many inappropriate git-answers regarding every version control related question, I do not love them either, but *sometimes* it might turn out to be acceptable solution. – altern Feb 17 '12 at 07:28
-1

Personally, I would use svn:externals too, but I would set up my repository differently

repo/trunk/src/mycode
repo/trunk/src/theircode
repo/branch/1.1/src/mycode
repo/branch/1.1/src/theircode

(and so on)

All of the "theircode" branches can easily be bound through svn external to their repository (their rev number). I wouldn't give away control over the entire trunk to an external repository, because if you decide you need to move your trunk in a certain direction you are bound in the wrong place to a repository you don't have direct control over. Yes, you could restructure then, but odds are you'll need to do that restructuring right when you need to do something else important, which means more pressure under less available time.

If you must "patch" their code, put that in the "your code" branch and extend your build system to copy their code into a "sources" build area. Then apply your patches. Don't modify their code in place, it's asking for trouble on many levels, include lots of levels which aren't apparent until it's too late.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • 1
    I am compelled to remind about the Occam's Razor after reading last paragraph, sorry. You make common mistake – Lazy Badger Feb 16 '12 at 21:29
  • @LazyBadger I can live with my "common mistake", but good luck convincing that your changes are your own, because you directly modified original code. Also, my patches probably will apply cleanly to the next release checkpoint I work with, or they will fail. With your solution, you'll need to merge. Not a terrible thing to do, but it definitely takes more work. Occam's Razor suggests that the simplest complete solution from a set of complete solutions is the best one to consider, not that a half-solution is better than a complete one. – Edwin Buck Feb 16 '12 at 22:01
  • 1
    Well, **my** solution is full, and merge is natural job of SCM. "good luck convincing that your changes are your own, because you directly modified original code" - can't see *any* problem comparing sources from 2 repos – Lazy Badger Feb 16 '12 at 22:12