Philipp von Weitershausen
2007-10-08 19:20:42 UTC
Since it has come up a few times on the checkins list recently, I'd like
to reiterate an important point:
When you split files or packages, you should always use 'svn cp' and not
simply copy the bare files. Because if you simply copy the files from a
checkout to another one, version history is broken. Using 'svn cp'
preserves version history. You can either start out by copying from one
repo URL to another, e.g.:
svn cp $z/foo.bar/trunk/src/foo/bar/snob $z/foo.snob/trunk/src/foo
or you can copy a remote set of files into a local sandbox (e.g. if you
want to modify them right away):
cd checkout-of-foo.snob/trunk/src/foo
svn cp $z/foo.bar/trunk/src/foo/bar/snob .
... edit files
svn ci
Note that this also applies to single files. E.g. when you split a long
module into two, use 'svn cp' to create the second file and then start
removing duplicate things from the original and the copy.
Why are we so anal about this? Because version history is important for
understanding why something was done and who did it. If we didn't need
to know this once in a while, we wouldn't have to use version control.
And if we didn't care for version history when copying, moving and
splitting files, we wouldn't have switched from CVS to subversion.
to reiterate an important point:
When you split files or packages, you should always use 'svn cp' and not
simply copy the bare files. Because if you simply copy the files from a
checkout to another one, version history is broken. Using 'svn cp'
preserves version history. You can either start out by copying from one
repo URL to another, e.g.:
svn cp $z/foo.bar/trunk/src/foo/bar/snob $z/foo.snob/trunk/src/foo
or you can copy a remote set of files into a local sandbox (e.g. if you
want to modify them right away):
cd checkout-of-foo.snob/trunk/src/foo
svn cp $z/foo.bar/trunk/src/foo/bar/snob .
... edit files
svn ci
Note that this also applies to single files. E.g. when you split a long
module into two, use 'svn cp' to create the second file and then start
removing duplicate things from the original and the copy.
Why are we so anal about this? Because version history is important for
understanding why something was done and who did it. If we didn't need
to know this once in a while, we wouldn't have to use version control.
And if we didn't care for version history when copying, moving and
splitting files, we wouldn't have switched from CVS to subversion.
--
http://worldcookery.com -- Professional Zope documentation and training
http://worldcookery.com -- Professional Zope documentation and training