Alan Jay Weiner wrote:
>>| >* Support for shared files. That is the same file being located in more
>
> (snip)
>
>>| Think of it this way:
>>| I've a large library of routines I use on most of my projects. No problem if
>>| it's an internal project; then I just carry around the whole library directory.
>>| But for clients, I just pull in the routines I use; I don't want to hand them my
>>| whole library. Since it's different files for different clients, I keep
>>| copying things around. And sometimes I'll add to the library functions that a
>>| particular project is using. Then I have to update all the other projects (base
>>| library plus any other projects using affected modules). PITA...
>>
>>So what would be the desired semantics? You'd want a file in one
>>subversion revision subdirectory to be 'hard linked' to a file in
>>another, such that it always is at HEAD? I assume that's what you
>>have to mean, else you could just use svn cp (or the GUI equivalent)
>>to make a zero-cost copy in the repository.
...
Please pardon the CVS terminology, but it's what I'm most familiar with
at the moment...
It sounds like you have 2 modules (commonlib and app, well maybe more
:-) and you want to have the ",v" files hard-linked between the module
trees. So yes, a change in one is an immediate change in the other, you
can go back and retrieve previous versions, etc. There have been times
I would have liked that, but never thought of it this way. (Hmm, I
wonder if that *would* work.)
Anyway, the bird in the ointment here (cause it's much bigger than a fly
:-) is tagging. If you've tagged your commonlib with something like
"v3", time goes on and files change, then later your app reaches version
3 also and you try to tag it "v3", then I'd say you've got big troubles
with the files that are in both modules. I don't know how to work
around that. Maybe SVN would/could handle that with some property, but
this issue (and possibly others) is a major one.
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 18 19:12:56 2004