Friday, June 19, 2009

svn and patches don't mix

Patch files are no fun. Look at this little bit from the SVN Red Bean Book
In this particular example, there really isn't much difference. But svn merge has special abilities that surpass the patch program. The file format used by patch is quite limited; it's able to tweak file contents only. There's no way to represent changes to trees, such as the addition, removal, or renaming of files and directories. Nor can the patch program notice changes to properties. If Sally's change had, say, added a new directory, the output of svn diff wouldn't have mentioned it at all. svn diff outputs only the limited patch format, so there are some ideas it simply can't express.

I only mention this because I've had a recent hiney bite in the combination of patch and svn.

2 comments:

  1. You might want to take a look at Mercurial's "queues" feature.

    http://www.selenic.com/mercurial/wiki/MqExtension

    Anything Subversion can do Mercurial can do better. ... Yes it can ... Yes it can.

    Git and (configured) Mercurial can at least express renames and copies in patch files with Git's extensions. I'm not so sure about creating empty directories though. But that's in the why would you want to do that category.

    ReplyDelete
  2. :-)

    Changing to DVCS is a topic we bring up often.

    SVN is the third version control in use on this project.
    1) Custom scripts on CVS first.
    2) Accurev next.
    3) SVN now.

    Probably next will be mercurial or git, but we're dealing with some larger architectural issues first. We've determined that svn isn't "the constraint" just yet. Two or three more in the way, then we can maybe make the jump.

    Thanks again for comments, pointers!

    ReplyDelete