I think a better way to do this is to use externals. Each project that uses
the library contains an external reference to the library (which may be
elsewhere in the same repository, or in a different repository). As long as
the project works with the current version of the library, the project
automatically inherits the latest library.
If the project can't work with the library HEAD, you can edit the external
reference to pin it to a particular revision of the library. Eventually,
when you get things worked out, you can remove the revision specification on
the external reference.
Dale
-----Original Message-----
From: Karan, Cem (Civ, ARL/CISD) [mailto:CKaran@arl.army.mil]
The reason I'm thinking about this is for 'libraries'; not real libraries,
but those code bases that seem to find their way into everything, but that
you never quite seem to bother turning into a real library. I've got some
lying around that, if changed, may break several older projects.
Unfortunately, I tend to change them on a regular basis (like when I find a
feature is actually a bug). Ideally, I could create working repositories
for each of those projects that include the library code. If I change the
code, then when I do a commit on the library, it just makes a new revision
for those projects. If I break something, then I can roll back to an
earlier version of the project.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 4 21:38:03 2004