What you are effectively saying is that I can work around this
deficiency in subversion by changing my project setup and redoing our
workflow to accommodate it. That's a very general solution for pretty
much any case where a tool is lacking a feature. The thing is,
sometimes it's not so easy to make those kinds of changes.
Hypothetical example, based on how I have used this feature in the
past... I have many utility files that are all stored in a utility
project, but only one of the files is needed by my project and it is
easier for other tools to manage if that file exists within my projects
source tree. The file must follow a standard format that should be the
same for all the projects that use it. Therefore it is best if there
really is only one 'current' version of that file that is shared
between multiple projects.
Like I said earlier, I don't really use the sharing feature much, but
it can be very handy for some cases, when factoring out the bits that
are shared to it's own unique project, used indirectly by all the
others doesn't fit well into the project structure.
It is true that refactoring as you suggest is often a reasonable
alternative, but is it always the best way? If you had the sharing
feature would you still refactor things that way? In all cases?
Scott
On Oct 6, 2004, at 5:40 PM, Tom McMillen wrote:
> You don't say where this need to have the same file 'shared' in
> different
> places comes from; but for any compiled code you could probably
> refactor
> this into a single utility library; this can then be referenced by
> other projects.
>
> Where I've used 'sharing' before with VSS was with asp files that
> go into more than location for a web site....
>
> With SVN I now have a single copy of the file in the repository, and a
> NAnt build script is used to deploy the file to different locations.
>
> Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 7 06:11:33 2004