Is it normal that SVN external files are not committed?

Question

I'm fairly new to Subversion and recently learned how to automatically import files which belong to other repositories using svn:externals. And now when I commit the trunk folder and create a tag to take a snapshot of the project, the files/folders defined as externals won't be added to the tag folder.

For example, I have this folder structure

Z:\repos\repoA

Z:\repos\repoB

Z:\Projects\workB

I have set svn:externals on Z:\Projects\workB to file:///Z:/repos/repoA/trunk/lib trunk/lib so that repoA's lib folder is automatically added to the current working directory, Z:\Projects\workB\trunk. And actually when I perform SVN Update, the lib folder is created under the trunk folder.

After editing some files and performing SVN Commit... on Z:\Projects\workB\trunk, I selected TortoiseSVN -> Branch/Tag from the context menu. In the To Path field, typed tags/1.0.1 and pressed OK. The 1.0.1 tag was successfully created.

After I performed SVN Update on Z:\Projects\workB\tags, a folder named 1.0.1 appeared but without external files.

Is this normal? I expected the imported files also would be there since they are in the trunk folder of the working directory.

---

I created two public repositories at Assembla for anyone to test this out.

• https://www.assembla.com/code/subversion-trouble-shooting/subversion/nodes
• https://www.assembla.com/code/subversion-troubleshoot-b/subversion/nodes

The second repository has the externals definition which pulls down the lib folder from the first repository. When I create a tag of the current trunk files from the second repository, it does not add the external files to the tag folder. Also when I check out the tag folder, it won't add the external files to the local working copy.

Cant

You shouldn't be committing to an external. Committing to an external implies that it is not external, but an active part of your current project. – Elsey

@Elsey - you are totally, absolutely, completely wrong. Commit into external resource is allowed, possible, must-have operation and additionally - it's UNRELATED to OP problem – Female

I didn't say it wasn't possible, I just said it was a bad idea. There an infinite multitude of things that are possible but are bad ideas. The conceptual idea behind externals is to be able to track version dependencies between your project and its external dependencies. It is not meant to be a tool to help administrate several repositories as one. But you are right it was unrelated to his problem. I see that now. – Elsey

svn:externals are a much abused hack. You really don't want to be using them as a poor man's dependency management system if you 'own' the source for all the projects. If you must use a an external strongly think about only using externals who's source is a tag. It's maddening to not be able to roll back your working copy to a prior state (the external still points to the trunk - you've not reverted anything) What language/tooling are you using? Look into ivy/maven/nuget or somthing similar. trust me - svn:externals are not the path. – Encephalomyelitis

@Encephalomyelitis What language/tooling are you using? - Currently I'm coding in PHP. I see your point that it gonna be a trouble if importing files get changed. In my case, they are all my files that I've created including the library files. And actually I need to update the second project if the first project gets updated. So in this particular case, svn:externals seems to be the perfect solution. Thanks for your insight. – Cant

@thekbb, re - "It's maddening to not be able to roll back your working copy to a prior state", pegging your externals revs solves this problem. – Sideward

Answer 1

When you set the externals property it does not copy the files from the external repository to your working repository. Rather it just creates a "note" on where to fetch those files from in future.

Thus, when you create your tag svn doesn't bother to copy the actual files that are externally linked. Instead it just copies the "note". Were you to perform a checkout of your tags/1.0.1 directory (or an update if it is already locally checked out) then you would notice that it would correctly pull down the relevant externals even thought these files do not exist in the working repository.

edit:

Ah, I've finally seen the problem. You set your external in the root directory rather than in the trunk directory.

The best way to view svn is that it is just a filesystem, the whole idea of trunk, tags and branches are just conceptual ideas and each directory is no different to the next.

Thus, when you copy trunk over to the tags directory the external properties do not get transferred as they are not part of the trunk directory (they only says to put external items in trunk). To solve you should remove the external properties from the root directory and add them to trunk. Next time you create a tag the external properties should be transferred.

The following command:

svn propget svn:externals file:///Z:/Projects/workB/trunk

should output:

file:///Z:/repos/repoA/trunk/lib lib 

Elsey

Thanks for the answer. Were you to perform a checkout of your tags/1.0.1 directory (or an update if it is already locally checked out) then you would notice that it would correctly pull down the relevant externals even thought these files do not exist in the working repository - Does not seem to work out this way in my environment. Please check out this tag 1.0.0 of the sample public repository I just created: assembla.com/code/subversion-troubleshoot-b/subversion/nodes/… When I check out this tag, it only pulls down the core_mod.txt. – Cant

To solve you should remove the external properties from the root directory and add them to trunk. - This was it. Thank you. Now when I create a tag, the external files are copied as well. – Cant

Answer 2

You expectation is correct. svn copy must create 100% copy of source object, i.e - external definition (and content) must appear in tag

1. Check svn ls -v -R file:///Z:/repos/repoB/tags/1.0.1
2. In order to easier check and troubleshot I'll suggest move to publicly available repo-set - for testing you can, f.e, create on Assembla free space with two or more SVN-repos

Unrelated to problem note: tag, by convention, used as code-freeze point (later from any point you can get exactly the same code), but it means, what you must also have locked all externals to the state of creating tag. repos/repoA/trunk/lib is HEAD revision, which changed over time and corresponding revision (link tag rev - lib rev)for tag 1.0.1 will be lost. Read about PEG-revisions

Edit

Tested Assembla repo with extension in trunk. Test failed:

>svn co https://subversion.assembla.com/svn/subversion-troubleshoot-b/trunk .
A    core_mod.txt
Checked out revision 4

only, there I had to checkout also /lib folder

Edit2

For subversion-troubleshoot-b repo: fixes applied to definition, created correctly-written tag (1.0.1) with external binded to PEG-revision

See differences between trunk and tag checkout

z:\>svn co https://subversion.assembla.com/svn/subversion-troubleshoot-b/
...

Fetching external item into 'subversion-troubleshoot-b\trunk\lib':
A    subversion-troubleshoot-b\trunk\lib\lib01.txt
Checked out external at revision 4.

Fetching external item into 'subversion-troubleshoot-b\tags\1.0.1\lib':
A    subversion-troubleshoot-b\tags\1.0.1\lib\lib01.txt
Checked out external at revision 2.

Checked out revision 7.

if you'll change lib in linked repo later - trunk will get latest content of folder, 1.0.1 - will be always with revision 2 of lib in subversion-troubleshoot

Female

Thanks for the answer. svn ls -v -R file:///Z:/repos/repoB/tags/1.0.1 just lists the files without the external files. I created an Assembla account and two public repositories and tested with them but the result was the same. Please see: assembla.com/code/subversion-trouble-shooting/subversion/nodes and assembla.com/code/subversion-troubleshoot-b/subversion/nodes The subversion-troubleshoot-b has the externals referring to subversion-trouble-shooting. – Cant

Please add this Assembla user as member to at least B-project. I'll commit good tree into repo – Female

Sent an invitation. Thanks for the concern. The problem was solved by setting svn:externals to the trunk folder, not the root folder as Dunes suggested. It may be better to leave the defect repository as it is for future readers. – Cant

@Teno: Fixed errors in repo, added good tag 1.0.1 - see differences – Female