On Apr 16, 2009, at 11:15, Luis A. Montes wrote:
> I'm wondering if there is a better way to handle lost/moved sources of
> an external than with a pre/post-commit script. Say folders A and B
> a svn:external property that point to file C (so is one of the 1.6
> externals) and C gets deleted. I want to change copy the last C
> into, say, A, delete it's externals property, and change B
> externals so
> that it points to A. And I want something simpler but similar if C is
> moved instead of deleted. I think I know how to do it, but that
> crawling through the repository and finding all the folders and
> their svn:externals with propget and parsing the results and ..., a
> cumbersome. Is there a better way?
I wouldn't have expected this to be a situation that would occur
often enough to warrant creating a script.
Maybe you're using externals more frequently than I, but I would just
make it a policy that developers shall not move, rename or delete a
directory that is shared code used by other projects. No, Subversion
doesn't provide a list of such places, but maybe the item's name or
its location in the repository would give a clue. For example, if all
your shared code is in a directory called "shared" then developers
should know not to move/rename/delete those items as they're probably
in use elsewhere.
You could create your own database of externals. Yes, you'd have to
crawl the entire repository, examining all directories for their
svn:externals property, to build the initial database, but then you
could use a post-commit hook to keep it up to date as the repository
changes revision by revision, which shouldn't be too bad. Then you
can make that database available to developers so they can know
what's where, and/or you can implement a hook script. I wouldn't try
to automate making a copy of the code, as you suggested; I'd instead
fail the commit if the developer tries to move/rename/delete
something that's in use elsewhere.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-18 12:24:19 CEST