scope of "local" PortGroup definition files

[Lawrence Velázquez]

On Jan 9, 2015, at 3:49 PM, René J.V. Bertin <rjvbertin at gmail.com> wrote:

> On Friday January 09 2015 13:14:16 Lawrence Velázquez wrote:
> 
>> Yes, you'd have to resolve conflicts in your repository. This happens less often than you'd think. I don't think it outweighs the benefits gained by having a simpler development setup.
> 
> Esp. one in which once every so often you don't wonder why things that worked "the other day" no longer work ... oh, wait, I did a selfupdate :)

Yes, exactly. No more weird shadowing issues, and conflicts are not overwritten without your knowledge.

> But if port sync uses `git rebase` when using git instead of svn, don't you lose local changes?

It uses `git pull --rebase` or `git svn rebase`, depending on your setup. Thus, uncommitted/unstashed local changes will cause the Git update to fail, although `portindex` still runs and updates your indices.

>> From whatever location the local repo uses as its remote. `port sync` just does a Subversion update or Git rebase.
> 
> That still doesn't explain how a local, file:// repo could get a remote location assigned to it (something my copy of sources.conf doesn't explain either, and I'm not fluent enough in Tcl to grasp the code at the link below without staring at it for a long time).

I don't understand your confusion. If the "repository" is a Subversion checkout or Git clone, it already knows where to pull updates from. If it's not, then it's simply not updated. And `portindex` refreshes the indices either way.

> Anyway, the change to using svn is exactly the sort of thing I'll try out first on my Linux box. I take it `port selfupdate` will still work?

I think so, but I'm not sure. I don't use `selfupdate` because I use base from trunk.

vq