On 11/01/2012 07:08 PM, Ryan Schmidt wrote:
On Nov 1, 2012, at 15:23, Blair Zajac wrote:
If I have no other work to commit in my tree, I'll just do 'svn commit' instead
of listing the paths to commit. In general, listing individual paths isn't a
great idea, since it's a practice that can mess up merging, where the
svn:mergeinfo property is changed on the root directory of a trunk or branch.
I always list paths when committing multiple ports, since I always have other
uncommitted work.
Right, I was just saying this as a best practice for coding work, not
working in MacPorts' ports tree.
I've sort of given up on Subversion merging for the MacPorts ports tree. I
understood how merging worked in Subversion 1.4 and earlier, but when merge
tracking was added in 1.5 it became confusing for me.
It's the same merging, there's just now merge metadata in the
svn:mergeinfo property attached to the directory where the merge was done.
Merging (or just "svn copy"ing) used to be the only way to ensure that a file
was only stored in the repository once, but now that Subversion has representation
sharing, the space savings are automatic.
Yes, but we still like to do 'svn copy' to retain history. svn isn't
like git where it'll put history together based on file contents alone.
We should still use merging for MacPorts base, of course, when we want to
backport a change from trunk to the release branch.
Yup.
Blair
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
