On Sat, 2009-04-18 at 03:35 -0500, Ryan Schmidt wrote:
> 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
> > have
> > a svn:external property that point to file C (so is one of the 1.6
> > file
> > externals) and C gets deleted. I want to change copy the last C
> > version
> > 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
> > implies
> > crawling through the repository and finding all the folders and
> > listing
> > their svn:externals with propget and parsing the results and ..., a
> > bit
> > 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.
Unfortunately, I'm working with a port from Source Safe to subversion,
and the way the code was done there it had plenty of shared files in
multiple directories. The catch is that I have some files with the same
names shared among two different sets of folders. So I would have to
create a different shared folder for each set of shared files. I did
look into this, but it got really ugly really soon. Or I could prepend
the folder name, but then if I delete that folder ... it gets messy.
>
> 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.
I do like the idea of the database, maybe something like SQLite should
work. The thing is that since I don't have a single shared folder I
think I'll have to automate the copy. Somebody working on a given
project has no way of knowing that a particular file is a source of a
share because that information is stored in other project's external
properties. Having them check the database every time they need to
delete a file seems cumbersome.
Maybe I'll implement the hook script that forbids the move as you
suggested, and wait to see how many people complain. If I see enough
hits, then I'll put the automated copy hook.
Thanks for the input,
Luis
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1827087
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-20 18:14:59 CEST