Subversion Incursion: Three Questions

Question #1
In a particular directory in my Subversion repository, I had made maybe ten subdirectories whose names were version numbers, missing their decimal points. Version 2.5.8 was directory name "258", 2.5.9 was "259", etc.

This stopped sorting correctly with version 2.5.10. D’oh!

So I wanted to change all the directory names to their full decimal point equivalents, and then commit the lot of ’em.

Trouble was, I mistyped one of my svn rename changes. I set one directory’s new location to be inside another directory’s new location. Quick, how could I undo that!?

I undid it by using the svn revert command on both the new location and the old location. But what about the case where one was inside another? I had a bad feeling about it, and I was right.

I wound up with Subversion thinking that one of the new locations was (a) an existing, checked-in directory, and (b) being moved to another branch (?). Like so:

    S  3.0.0

Multiple subsequent uses of svn revert were unable to change Subversion’s mind.

Now, the easiest way to undo all this is probably to nuke the working directory and check it out again.

But I’m never one for easy, so I decided to try mucking with the contents of the local .svn directories.

The .svn/entries file has a list of all the files, with changes. Each file is represented by an <entry/> tag. The schedule attribute seems to describe the rename directives I’ve been making.

But hand-editing this file didn’t change the result of a svn status call.

I didn’t want to screw around with it, so I nuked the directory and started over. This time I set up the svn rename calls ahead of time in a text file and double-checked them, so I would get them right the first time.

Has anyone had success hand-edited these entries files?

Question #2
Inside those version number directories mentioned above are code archives. I needed to update my code directories with files from within those the archives. Replace both files and files within subdirectories and files with subdirectories of subdirectories.

In fact, under normal circumstances, I would have just taken the directory that each archive expanded to and dragged that over to replace its code directory twin, because my code directories have the same layout as the archives.

But now that my files are in a Subversion repository, I had to worry about all those little hidden .svn subdirectories. If I just replaced a top-level directory in the repository with a directory from elsewhere via the Finder, all the .svn instances would vanish.

So: is there a utility that will do such a nested copy without actually replacing the directories themselves (and thus deleting their hidden contents)?

Question #3
Once the new files had been copied over, I needed to add them all to the repository. Oops! svn add requires you to specify the exact file (or maybe the location of the files?) to be added. But I’ve got a hundred of new files in a score of different directories.

Text files to the rescue again. I copy the results of an svn status call into BBEdit and sort the lines, so all the lines that start with ? come first, then manipulate the text a little more to get a list of svn add commands.

Is there an easier way?

11 thoughts on “Subversion Incursion: Three Questions”

  1. You appear to be pretty capable with Subversion — can you envision a workflow or scripting solution that would enable Subversion to work with an iPhoto library to allow multiple powerbook users to all share and sync to a single iPhoto Library on a server?

  2. Darin —

    It’s not something I’d spend effort on.

    You’re trying to combine two technologies in a way that neither was designed to be used.

    Subversion is a CVS replacement, which means it’s for developers. It’s geared towards power and details over ease-of-use and behind-the-scenes syncing. (.Mac is probably a better fit for the last.)

    iPhoto as far as I know does not have any collaborative capabilities in its save format, but I haven’t investigated it.

    I understand the impulse of wanting the convenient UI of iPhoto to use in a collaborative environment. But it’s going to involve so many hacks to iPhoto and so many extra capabilities on top of Subversion (you’ll have to write your own client to connect from iPhoto to the server) that it just doesn’t seem worth it.

    I mean, c’mon, sign up for a free Flickr account. That gives you access to photos from multiple machines for a lot less work.

  3. I’m looking for that very same thing, your question #2. Any luck???

    I knew I wasn’t the only person in the world with that problem.

  4. Right. Which means that when you write the utility that allows someone to do that (with a nice-looking graphical interface, of course), many people will be grateful. 🙂

Comments are closed.

%d bloggers like this: