views:

111

answers:

1

I'm trying to add something like:

subdir
  modules
    module1ext
    module2ext
    module3NOText
  other dir not from externals

in which subdir/modules/module{1,2}ext are defined in externals specifically, but not /subdir nor /modules.This basically adds module{1,2}ext to the svn repo, but not subdir and modules.

So, now I want to add a directory under subdir (other dir not from externals) or modules (module3NOText) and I can't because the parent directories aren't under svn. Should I just svn add them? Won't that mess up the externals definition?

Also, let's say I want to modify module1ext. I was thinking of removing the externals definition and then svn add that dir. From my experience, that works, but can you tell me if it has any downside or if it should be done at all?

+1  A: 

You seem to have something mixed up here.

Your repository should look like:

trunk
   subdir
     modules ---------> property svn:externals with links to module1ext and module2ext
        module3NOText
   otherdirnotfromexternals

When checking out the trunk, all folders (subdir, modules, module3NOTExt, otherdirnotfromexternals) are under svn version control. Modules should contain the two external modules (if the svn:externals property is set correctly).

So adding a directory under subdir or modules should be done through svn add.

If you want to modify the external code, you probably also want to keep up with possible changes in the original repository. In other words, you want to create a branch.

  • if the code is in the SAME repository, you can simply use svn copy to create a branch, and use svn merge
  • if the code is in another repository, you can manage this as a vendor branch. In a nutshell: you import the code in your own repository, tag it to mark the point you started from, branch it to your own project and make your modifications from there. For merging changes in the original code, you import the new version in your vendor branch, tag it again and merge the changes into your project branch.
jeroenh
Actually, the idea is to use vendor branches to a core repo (technically a branch but I mostly use hg these days so...), then have multiple repos deriving from that core via svn:exports. All the merges are made at core level and then, svn:exports takes care of propagating them. The diff between the core and the derived repos are the aditional modules. I found that svn:externals are treated as an independent repo and subdirs leading to it aren't added automatically, you really need to svn add and then you get the structure you mentioned. Thanks.
Neo
@Neo can you elaborate on what you mean by "svn:externals are treated as an independent repo and subdirs leading to it aren't added automatically"? I don't understand this...
jeroenh