Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is it normal that SVN external files are not committed?

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.

like image 726
Teno Avatar asked Oct 16 '12 10:10

Teno


2 Answers

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 
like image 165
Dunes Avatar answered Oct 12 '22 01:10

Dunes


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

like image 24
Lazy Badger Avatar answered Oct 12 '22 01:10

Lazy Badger