move port to new category

[Blair Zajac]

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