> Alex R. Mosteo wrote:
>
> > [Nick Seigal:] ... a tag of my project containing
> > externals should only be containing externals pointing at other tagged
> > and unchanging repository codelines. These should never be changed or
> > deleted (hence the idea of a "tag"), and I can insure this, since we
> > maintain our own vendor-library and internal-library branches and
> > their policies ...
>
> Thanks Nick, I've too arrived to this conclusion. My case is a bit more
> annoying because I'm modifying the external library too from the main
> project, so I can't link to a "frozen" revision of the library ATM. Thus
> when I make a milestone for the project, I must go to make tags for all
> the external libraries involved and make new external ad-hoc properties
> for the milestone tag.
Of course your method does *work* (with some manual effort). I think a more
de-coupled strategy may work better. I suggest that, if possible, you *not*
modify the external library "from the main project". This was my old
working method and getting rid of it was key in my improving my source
control strategy.
It seems to me that a good process rule is that shared products should be
developed in their own workspaces. Personally, I find it useful to create
custom test-clients to develop and test my shared libraries against, so that
I am assured that each is truly going to work for more than just the one app
I've linked it to so far.
If you wish to, you can set up both workspaces (e.g. those of the core app
and a library it depends on) to "external" each other at the appropriate
branches and revisions, and use the main app *as* the "test-client" for the
shared library.
If the library is not going to be shared (but seperating it from the core
app is just for modularity in a multi-tier deployment for example), then I
put it in the same working directory heirarchy as the core app (in a
subfolder) *but* I wouldn't then need externals as I would have its
repository in a subfolder of the core app's repository.
The rules I follow for minimizing dependency issues are:
1. If an internally developed library is part of one project and not
planned for use in any other, then it should be put somewhere under the same
workspace and repository tree so that it can be developed and versioned
along with the main project.
2. If an internally developed library is to be shared between multiple
projects, then it should be developed from its own workspace and have its
own repository and versioning. From the perspective of project developers,
it should be treated like a closed-source vendor drop. To use it, link it
to the main projects via externals pointing at tagged release versions of
the library. Project developers may also be library developers where
appropriate and authorized.
3. If an external vendor library is open-source, treat it as a vendor
drop. To use it and develop against it, merge it into the main project.
Merge patches to the library back to the vendor drop (or even back to the
vendor) where appropriate and authorized. (We don't do a lot of this
yet...)
4. If an external vendor library is closed-source, treat it as a vendor
drop. To use it, link it to the main projects via externals pointing at
tagged release versions of the library. (We do a lot of this though!)
These rules reflect a strategy that is still in its infancy. We need to get
more experience with it to identify its flaws. It does seem to require a
bit more on the client-side in terms of workspaces, but it is more clearly
organized in terms of workflow and responsibilities and doesn't require
complex or manual kludges to the externals.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 18 20:48:51 2005