martin f krafft wrote: > So let's say ~/some/path/.mrconfig specifies > > [subdir] > checkout = … > chain = true > > and ~/some/path/subdir/.mrconfig specifies > > [another] > checkout = … > > then, with the status quo, running mr in ~/some/path will work on > two repos, as it should.
This is already how mr behaves, as long as ~/.mrconfig chains to ~/some/path/.mrconfig. > However, running mr in ~/some/path/subdir will only run over > "another", not the repo in the CWD itself, and I don't really see > why it should do that. If ~/.mrconfig does not chain to ~/some/path/.mrconfig, then mr is left looking for the first .mrconfig file it can find at or under the current directory. So, when run in /some/path/subdir/, it finds that .mrconfig, and ~/.mrconfig, but not any other .mrconfigs you may have scattered around, and behaves as you describe. The solution, then, is to use chaining from ~/.mrconfig ... Regarding the original message in this bug report: mr status: /home/madduck/debian/debconf/team/pub-data mr status: /home/madduck/debian/debconf/team/pub-data/. Yes, it can sometimes make sense to have a [.] entry in a .mrconfig. d-i does this for example. And then you get a duplicate entry for that. A solution might be for mr to do path normalization and throw out such duplicates. But then that leaves the knotty question of which one to throw out, the [.] one or the one in the parent repository that chains to it? Both could concevably have different update or other actions defined.. Perhaps, then, it's best to leave this to the mr user to decide. It's easy enough to configure mr to not update in one of the duplicates if desired. For example, after noticing I had this problem in my configuration, I now have: [d-i] checkout = svn co svn+ssh://jo...@svn.debian.org/svn/d-i/trunk d-i chain = true update = : # handled by d-i's mrconfig -- see shy jo
signature.asc
Description: Digital signature