My collaborators and I often find that we would like to be able to set different svn:ignore and svn:externals properties for our own working copies of a project. It doesn't seem like the svn functionality related to the properties requires that those properties be versioned, but we haven't yet found a way to unversion these properties.
views:
47answers:
4
+2
A:
No, properties are specific to the file/directory they are set on. User-specific properties do not exist.
Why do you need different svn:externals? One way of dealing with that is to have your own directory in the repository containing only externals. That way you can control your own set of externals.
The conventions and layout of the repository is something that you have to agree on. Subversion does not really allow users to customize their view of the repository.
JesperE
2009-08-20 07:49:49
A:
To unversion these properties, delete them from the folder or file they're attached to (then commit). If you're using the command line you can use "svn propdel" to remove them.
Properties in SVN are stored on the server, they are not working-copy constructs, so you cannot have the same property set for different users.
To get different 'views' of the same code, you might like to look into branching instead, each of you work on your own branches and regularly merge your changes into the trunk. That sounds like the workflow you're trying to achieve with different properties per user.
For a different way of looking at svn:ignore, you can set different 'global-ignores' on your clients.
gbjbaanb
2009-08-20 07:52:24
Thanks! This is a good answer to my question. It really looks like branching is the best way to acheive what I'm trying to do, although it isn't especially convenient. This is something of a niche application, as it involves using the CAD program CADENCE together with svn, but that leads to good reasons for wanting this kind of capability. Even though it is a niche application, it seems like implementation of this capability shouldn't be too hard (there are already user-defined properties that can be versioned or not). Maybe on some future release...
2009-08-20 18:55:07
the problem is: where would you put these properties, as they live on the server. Adding per-user props to each file would quickly get unmanageable. Branching is what you want, its much more convenient than you think once you've done it twice, and significantly more powerful as you'll find out when you start to realise what else you can do using it.
gbjbaanb
2009-08-20 18:59:55
A:
Muhahahahaha!
A totally impractical solution to getting user-specific (well, actually workstation-specific) svn:externals:
First, Have each developer create a subversion repository on their own machine, and run a little svnserve instance to make it accessible.
svn://localhost/local-externals
Have each developer set their perferred svn:externals property on the root directory of said repository.
svn co svn://localhost/local-externals
svn pe svn:externals local-externals
...
svn commit local-externals
In your central repository, include an svn:externals reference to svn://localhost/local-externals
svn co svn://example.com/repo/project/trunk
svn pe svn:externals
... define an reference to svn://localhost/local-externals
svn commit trunk
Now, each developer checking out the trunk will get their externals directory from their local externals repository pulled in, which can in turn pull in the parts of the main repository they want to have included in their checkout.
You could do this, but I think I'd consider myself certifiably insane for even considering this.
bendin
2009-08-20 07:57:06
+1
A:
Think of SVN as a file system. If you wanted to achieve your goals, what would you do in a file system? Each of you would create a copy of the original files somewhere.
You can do the same with Subversion (svn copy). Properties set in the new subdirectories will only be valid for those subdirectories and not for the original files.
But there is a price: You now have to synchronize (merge) your changes manually (just like you would have to do when you do this in the local filesystem without subversion).
I'm not aware of any VCS which allows what you want for free.
Aaron Digulla
2009-08-20 08:00:43