Best way to handle shared files in SVN?

[Robert Denton <ro...@headsprout.com>]

Hi all,

Thanks for listening.  I am wondering what is advised as to the best  
way to handle shared components across multiple projects in SVN.   
Here is the situation:

My boss, who has always used VSS before the introduction of SVN on  
our network, likes to use shared libraries, etc in his projects and  
will have the same file in a number of different locations.  In VSS  
he could just drag and drop the shared file into new projects and VSS  
knew it was 'shared' component and any change made to it would apply  
in all instances.

With TortoiseSVN being a shell extention (and thus a different beast  
entirely) we are not sure if simply creating a plain old file system  
shortcut is sufficient to emulate this behavior. Is there some other  
method or property used by Subversion to make a file as 'shared'?

Thanks for any and all input on this issue.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Best way to handle shared files in SVN?

[Ted Dennison <de...@ssd.fsi.com>]

John Burwell wrote:
>> So given that svn:externals does not equate to VSS sharing, what
>> other solutions have people come up with to achieve this?
>
> I get annoyed when people respond to my questions with new problems 
> instead of solutions, but there are times, I think, when system 
> transitions like the one you've undertaken simply require adaptations 
> in workflow. This might be an opportunity for you to re-evaluate some 
> of your older procedures and develop new habits to take better 
> advantage of the facilities Subversion *does* provide.
I'd second this. If sharing of controlled files was an otherwise 
universal source control management feature it might be different. 
However, I've now used (*counts on fingers for a bit*) 6 different 
source control management tools in my time, and VSS is the only one that 
had this feature. Its kinda nice, but the transparent nature of it can 
cause problems too. Someone can easily break the link without you 
knowing, or make changes that only work in one environment without 
knowing they need to break the link.

Of course most of those SCM tools wouldn't have needed a sharing feature 
either, as their OS's supported soft links. VSS's sharing feature can 
perhaps be looked at as a hack to work around a failing of the Windows OS.

If you are using the NTFS file system on Windows, its possible to create 
softlinks ("junctions" in Micro$oft-speak). There isn't a lot of good OS 
support out of the box for them, but there are several free downloads 
that help. Some are even from Micro$oft. Google for Windows and junction 
and you should be able to find something useful. Junctions can only be 
directories though (same limitation as the SVN workaround mentioned 
previously). Also, I'd guess SVN can't tell it from a file, so you might 
have to handle it specially (eg: put it in some kind of ignore list, and 
add a rule in your makefile to recreate it when needed).

Supposedly with Windows Vista there will be a "mklink" command that will 
support making file symbolic links. Hopefully, when this becomes 
available SVN will support them, as it supports them for Unixes?

-- 
T.E.D.   Work     -  mailto:dennison@ssd.fsi.com
         Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
         Homepage -  http://www.telepath.com/~dennison/Ted/TED.html

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Best way to handle shared files in SVN?

[John Burwell <jo...@galvnews.com>]

> So given that svn:externals does not equate to VSS sharing, what
> other solutions have people come up with to achieve this?

I get annoyed when people respond to my questions with new problems  
instead of solutions, but there are times, I think, when system  
transitions like the one you've undertaken simply require adaptations  
in workflow. This might be an opportunity for you to re-evaluate some  
of your older procedures and develop new habits to take better  
advantage of the facilities Subversion *does* provide.

For example, you may find benefits in splitting your shared libraries  
and common files out into separate projects you can manage  
independently. Development on these common components can proceed  
separately from your main projects, revisions to the common code  
won't be tied up in revisions to main project code, and with  
Subversion's branching and tagging features, you can even maintain  
build compatibility with older projects by linking them against older  
tags.

It may require some changes to your main projects, however. In  
projects I work on, I make sure code that references shared libraries  
refers to a common location not specific to any individual project  
(like a /lib directory, for example). If the libs are there, great.  
If not, the compile fails (in the case of source libraries) or the  
application dies with an error (in the case of runtime libraries) --  
but these are coding practices, not versioning practices. As far as  
versioning is concerned, putting the libs where they go is a simple  
matter of dropping a working copy of the lib project in the global  
location, at which point everything snaps back into place.

I hate to say it, but if your code doesn't already do this, or isn't  
easily adaptable to such a scheme, you may be facing a problem for  
which a version control workaround is not a sustainable solution anyway.

Maybe you can present the case to your boss that there have been long- 
standing vulnerabilities in your current workflow that you can  
finally address now that you're on Subversion, among them being the  
need to link shared files into multiple projects all over the place,  
with the version inconsistencies and accountability headaches that go  
along with that. Now that you're away from the VSS way of doing it,  
you can build more robust applications with standalone components,  
The Subversion Way(tm).

j

RE: Best way to handle shared files in SVN?

[Gavin Lambert <ga...@compacsort.com>]

Quoth Robert Denton <ma...@headsprout.com>:
> So given that svn:externals does not equate to VSS sharing, what
> other solutions have people come up with to achieve this?

Make libraries and componentise the code rather than randomly sharing
files all over the place.  Gives you much better design and structure
for your code.

Then, rather than using externals, simply check out both together in
some known relative position (eg. elsewhere in trunk, assuming you check
out the whole of trunk at a time), and simply refer from one to the
other via relative paths.  Make sure you avoid circular
references/dependencies, though.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Best way to handle shared files in SVN?

[Robert Denton <ro...@headsprout.com>]

On Sep 6, 2006, at 2:16 PM, Andy Levy wrote:

> On 9/6/06, Robert Denton <ro...@headsprout.com> wrote:
>> Thanks for listening.  I am wondering what is advised as to the best
>> way to handle shared components across multiple projects in SVN.
>> Here is the situation:
>>
>> My boss, who has always used VSS before the introduction of SVN on
>> our network, likes to use shared libraries, etc in his projects and
>> will have the same file in a number of different locations.  In VSS
>> he could just drag and drop the shared file into new projects and VSS
>> knew it was 'shared' component and any change made to it would apply
>> in all instances.
>>
>> With TortoiseSVN being a shell extention (and thus a different beast
>> entirely) we are not sure if simply creating a plain old file system
>> shortcut is sufficient to emulate this behavior. Is there some other
>> method or property used by Subversion to make a file as 'shared'?
>
> TortoiseSVN is simply a Subversion client.  You probably want to use
> svn:externals to link another section of your repository (or a
> resource in a whole other repository) to your project.  You can only
> set svn:externals at a directory level; you can't "share" a single
> file into another directory (I think VSS let you do this).
>
> http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

Hm.

I have googled on the matter to some degree and the general  
concensus, as far as I can tell, is that this is a highly sought  
after feature, and most of the posting I saw argued that using  
svn:externals is NOT a solution, nor a work-around, since you can  
only apply that property to folders and not files.

So given that svn:externals does not equate to VSS sharing, what  
other solutions have people come up with to achieve this?

I hope me and my boss are not the only two people on the planet who  
valued this feature in VSS. Are there any plans for building it into  
SVN?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Best way to handle shared files in SVN?

[Andy Levy <an...@gmail.com>]

On 9/6/06, Robert Denton <ro...@headsprout.com> wrote:
> Thanks for listening.  I am wondering what is advised as to the best
> way to handle shared components across multiple projects in SVN.
> Here is the situation:
>
> My boss, who has always used VSS before the introduction of SVN on
> our network, likes to use shared libraries, etc in his projects and
> will have the same file in a number of different locations.  In VSS
> he could just drag and drop the shared file into new projects and VSS
> knew it was 'shared' component and any change made to it would apply
> in all instances.
>
> With TortoiseSVN being a shell extention (and thus a different beast
> entirely) we are not sure if simply creating a plain old file system
> shortcut is sufficient to emulate this behavior. Is there some other
> method or property used by Subversion to make a file as 'shared'?

TortoiseSVN is simply a Subversion client.  You probably want to use
svn:externals to link another section of your repository (or a
resource in a whole other repository) to your project.  You can only
set svn:externals at a directory level; you can't "share" a single
file into another directory (I think VSS let you do this).

http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org