>| >* 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.
If I'm following your terminology, yes.
In SourceSafe, you can "share" a file from one directory to another. Changing
it *anywhere* changes it *everywhere*.
In my case, if I add a routine to one of my library files, I want that file
updated everywhere - so in Subversion, I'd just do an update (on other projects)
and it'd get the latest.
>In a UNIX environment you could just add a rule to zero-cost copy the
>HEAD file(s) into your working environment at build time, couldn't
I don't want to *copy* the file; I want all projects that "share" that file to
reference the same file; if it's changed in one project, it's changed for all
projects. If I copy it, then I have to change it in the copy-source-directory,
which is not where I'm working; I'm working on project "foo" and I change the
shared file there, then check it in to project "foo" and that checkin changes it
in all other places - including my "commonlib" project which is the place where
the file actually lives.
>you? You wouldn't want to lose the ability to check out/export a
>given build in the state that it was in when you did validation, would
>you? I'd hate to create a Subversion checkpoint for my software and
>then go back a couple of years later and have some files not be as
>they were when I built and tested the checkpoint..
Ok, that's reasonable - I agree; you definitely want to get a particular build's
files exactly as they were at that time.
Are you saying that svn:externals always gets from HEAD? So if I "go back in
time" and get an older revision of a project which uses svn:externals, it'll get
the project's files from the proper revision, but the external files from that
other project's HEAD?
If that's true, then my separate-directory idea wouldn't work; I'd never be able
to go back to older revisions without a lot of manual work.
- Al -
--
-- Alan Weiner -- alan_at_ajw.com -- http://www.ajw.com
Palm OS Certified Developer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 18 07:02:18 2004