Re: Ipfilter pre-Vendor Import Issue
On Mon, Jul 08, 2013 at 01:00:02PM -0700, Cy Schubert wrote: C The BSD license allows us to put the code into FreeBSD w/o any separation. C C So the question is: what is more handy to us? C C What do we actually gain having contrib/ipf, assuming we got vendor branch C already? C C What we lose is: C - more complex Makefiles C - more complex hacking: edit files in one place, run make in other C C How is this for a plan? C C Instead of importing the kernel bits into vendor-sys/ipfilter and the C userland bits into vendor/ipfilter, the base tarball should be imported C into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We C keep the complete tarball imported into one place in the tree. I'd prefer vendor/ipfilter as single place of vendor imports. C Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and C netpfil/ipfilter (for userland bits). C C We should probably think of moving pf and ipfw into the new subdirectory as C well, but that's for a future discussion. No, userland tools should be placed in bin|sbin|usr.bin|usr.sbin, according to the place where they are installed. An exlusion can be made adding a intermediate subdir (like this is already done for ipfilter tools), to group all related tools together. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
On Mon, Jul 8, 2013, at 11:26 AM, Andre Oppermann wrote: I think the main distinction here is whether the adaptions to FreeBSD are kept local (resulting in almost a fork) or are fed upstream so that successive updates require less or no local changes. Having the kernel part in sys/netpfil certainly makes it easier for kernel people to adjust it to changed realities. IIRC ipfilter also has very messy ifdef's all over the place for every possible ancient version of FreeBSD. This probably should be cleaned up (and upstreamed) as well. At one point in time, I believed that this was the right thing to do as it allowed new code to work with older systems. That was back when there was little ifdef's... now it is #ifdef hell. However almost nobody cares about this so at some point in the future, I'll join with the masses and new versions or patches will just work with the latest whatever. If the code being imported removed lots of ifdef code that is irrelevant, I don't think anyone will be upset... Cheers, Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
On Tue, Jul 9, 2013, at 11:21 AM, Gleb Smirnoff wrote: ... No, userland tools should be placed in bin|sbin|usr.bin|usr.sbin, according to the place where they are installed. An exlusion can be made adding a intermediate subdir (like this is already done for ipfilter tools), to group all related tools together. The structure NetBSD have adopted for vendor code is to have (for example) src/usr.sbin/ipf and for the Makefiles to reference the vendor code in src/dist/ipfilter. Do you see that working for FreeBSD or would you prefer to have source code live with Makefiles? Cheers, Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
On Friday, July 05, 2013 4:46:49 am Gleb Smirnoff wrote: Cy, On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote: C Unfortunately it doesn't work any more. Here is what svn spit out at me. C C slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter C slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfilte C r/dist@252548 C svn: E205000: Try 'svn help merge' for more information C svn: E205000: Source and target must be different but related branches C svn: E205000: Source and target have no common ancestor: C 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist@252548' and C '.@unspecified' C slippy$ AFAIU, the problem is that current contrib/ipfilter was never merged from vendor/ipfilter. So, actually we are dealing with a first import (from subversion viewpoint), not n-th. What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? Because we put all other vendor code in contrib/ by convention. When there is vendor code in other places it usually results in confusion. For bits that have userland and kernel bits we use head/contrib and head/sys/contrib pulling from vendor/foo and vendor-sys/foo, respectively. Also, this is not the first import as we used a CVS vendor branch for IP filter previously that svn2cvs preserved. Cy, for your svn merge you said you would do this: cd $MY_WORK_DIR/current/contrib/ipfilter svn merge --record-only \ svn+ssh://svn.FreeBSD.org/base/vendor/ipfilter/dist@NNN cd $MY_WORK_DIR/current/sys/contrib/ipfilter svn merge --record-only \ svn+ssh://svn.FreeBSD.org/base/vendor-sys/ipfilter/dist@NNN but instead you did this: slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfilte r/dist@252548 Notice you are using 'file:///tank/', not the official SVN repository. All your checkouts and merges should be done using svn.FreeBSD.org, not a local mirror. That might explain your merge problem. Also, if you are just updating the existing vendor branch and not updating it to a newer version I'm not sure you really need the @NN part for the bootstrap merge, but it probably doesn't hurt. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
On Tuesday, July 09, 2013 5:21:36 am Gleb Smirnoff wrote: On Mon, Jul 08, 2013 at 01:00:02PM -0700, Cy Schubert wrote: C The BSD license allows us to put the code into FreeBSD w/o any separation. C C So the question is: what is more handy to us? C C What do we actually gain having contrib/ipf, assuming we got vendor branch C already? C C What we lose is: C - more complex Makefiles C - more complex hacking: edit files in one place, run make in other C C How is this for a plan? C C Instead of importing the kernel bits into vendor-sys/ipfilter and the C userland bits into vendor/ipfilter, the base tarball should be imported C into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We C keep the complete tarball imported into one place in the tree. I'd prefer vendor/ipfilter as single place of vendor imports. C Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and C netpfil/ipfilter (for userland bits). C C We should probably think of moving pf and ipfw into the new subdirectory as C well, but that's for a future discussion. No, userland tools should be placed in bin|sbin|usr.bin|usr.sbin, according to the place where they are installed. An exlusion can be made adding a intermediate subdir (like this is already done for ipfilter tools), to group all related tools together. Please, please! Let's not make ipfilter some random one-off vendor source that imports code into random places. The remaining instances of that that we have (such as stdtime) are a PITA to deal with. vendor/ipfilter == userland bits = contrib/ipfilter. You then put suitable Makefiles/build glue that uses .PATH in usr.bin|sbin|whatever. vendor-sys/ipfilter == kernel bits = sys/contrib/ipfilter. You then fix sys/conf/files, etc. as appropriate. This is our _standard_ practice for dealing with this stuff. This is how all the OpenSolaris bits for Dtrace and ZFS are handled (except that they end up in a cddl directory instead of contrib). GENERIC / LINT builds can include things from sys/contrib just fine, so ipfilter won't be missed by builds, etc. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
On Tue, Jul 09, 2013 at 12:49:36PM -0400, John Baldwin wrote: J Let's not make ipfilter some random one-off vendor source that imports code J into random places. The remaining instances of that that we have (such as J stdtime) are a PITA to deal with. J J vendor/ipfilter == userland bits = contrib/ipfilter. You then put suitable J Makefiles/build glue that uses .PATH in usr.bin|sbin|whatever. J J vendor-sys/ipfilter == kernel bits = sys/contrib/ipfilter. You then fix J sys/conf/files, etc. as appropriate. J J This is our _standard_ practice for dealing with this stuff. This is how all J the OpenSolaris bits for Dtrace and ZFS are handled (except that they end up J in a cddl directory instead of contrib). GENERIC / LINT builds can include J things from sys/contrib just fine, so ipfilter won't be missed by builds, etc. Okay, let it be so. My initial intention was to own ipfilter by FreeBSD, since for the last years it was unmaintained, and its contrib status prevented people from touching its sources. Now, that Darren responded on this thread and promises to take our patches upstream, I am fine with having it in contrib. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
On 05.07.2013 20:38, Cy Schubert wrote: In message 20130705084649.gc67...@freebsd.org, Gleb Smirnoff writes: What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter Having ipfilter in one place instead of two (vendor and vendor-sys) makes a lot more sense. I suppose we could put ipfilter's kernel components in sys/netpfil but what about the userland sources? Also see my reply below regarding keeping it in contrib. In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? The reason to keep ipftilter in contrib is to maintain consistency with other contributed software such as bind, nvi, sendmail, pf, and a host of other notable software we don't maintain ourselves. Maintaining consistency with other contributed software should probably be maintained. I'm open to moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as long as consistency is maintained across the board. Do you think we should put the userland sources also in the same location or should we maintain a similar separation we do today? I'm open to both however I'd prefer keeping all vendor software (kernel and userland) in one location. I think the main distinction here is whether the adaptions to FreeBSD are kept local (resulting in almost a fork) or are fed upstream so that successive updates require less or no local changes. Having the kernel part in sys/netpfil certainly makes it easier for kernel people to adjust it to changed realities. IIRC ipfilter also has very messy ifdef's all over the place for every possible ancient version of FreeBSD. This probably should be cleaned up (and upstreamed) as well. -- Andre ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
Cy, On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote: C What I'd prefer to see is the following: C C - commit new ipfilter untouched to vendor-sys/ipfilter C - nuke sys/contrib/ipfilter C - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter C C Having ipfilter in one place instead of two (vendor and vendor-sys) makes a C lot more sense. C C I suppose we could put ipfilter's kernel components in sys/netpfil but what C about the userland sources? Also see my reply below regarding keeping it in C contrib. IMO, it is possible to keep a bulk checkout of ipfilter in vendor/ipfilter, but merge kernel files separately to sys/netpfil/ipfilter, and separately merge userland files to appropriate place. C In future imports do: C C - commit newer ipfilter to vendor-sys/ipfilter C - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter C C What's the reason to keep code in contrib? C C The reason to keep ipftilter in contrib is to maintain consistency with C other contributed software such as bind, nvi, sendmail, pf, and a host of C other notable software we don't maintain ourselves. Maintaining consistency C with other contributed software should probably be maintained. I'm open to C moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as C long as consistency is maintained across the board. C C Do you think we should put the userland sources also in the same location C or should we maintain a similar separation we do today? I'm open to both C however I'd prefer keeping all vendor software (kernel and userland) in one C location. The BSD license allows us to put the code into FreeBSD w/o any separation. So the question is: what is more handy to us? What do we actually gain having contrib/ipf, assuming we got vendor branch already? What we lose is: - more complex Makefiles - more complex hacking: edit files in one place, run make in other -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
In message 51da85cf.3000...@freebsd.org, Andre Oppermann writes: On 05.07.2013 20:38, Cy Schubert wrote: In message 20130705084649.gc67...@freebsd.org, Gleb Smirnoff writes: What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter Having ipfilter in one place instead of two (vendor and vendor-sys) makes a lot more sense. I suppose we could put ipfilter's kernel components in sys/netpfil but what about the userland sources? Also see my reply below regarding keeping it in contrib. In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? The reason to keep ipftilter in contrib is to maintain consistency with other contributed software such as bind, nvi, sendmail, pf, and a host of other notable software we don't maintain ourselves. Maintaining consistency with other contributed software should probably be maintained. I'm open to moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as long as consistency is maintained across the board. Do you think we should put the userland sources also in the same location or should we maintain a similar separation we do today? I'm open to both however I'd prefer keeping all vendor software (kernel and userland) in one location. I think the main distinction here is whether the adaptions to FreeBSD are kept local (resulting in almost a fork) or are fed upstream so that successive updates require less or no local changes. I see no problem feeding update upstream. The email I just received from Darren (cc'd Gleb and yourself) is likely to lead to this kind of relationship. Having the kernel part in sys/netpfil certainly makes it easier for kernel people to adjust it to changed realities. True. I'm thinking we should do the same with the userland side of ipfilter, keeping everything consistent. Also, I think putting all of the vendor bits regardless of whether they're destined for kernel or userlan into vendor/ or vendor-sys/ should make it simpler as well. What are your thoughts? IIRC ipfilter also has very messy ifdef's all over the place for every possible ancient version of FreeBSD. This probably should be cleaned up (and upstreamed) as well. Yes. There's a lot of cruft in there for operating systems that are no longer relevant as well. At least we can push some of the FreeBSD cleanup upstream. Initially I'd like to import v5-1-2 into our vendor branch (either vendor/ or vendor-sys/ for the complete tarball) then svn merge into sys/netpfil/ (for kernel) and netpfil/ (for userland). Do you have any additional thoughts on any of this? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
In message 20130708134400.gh67...@glebius.int.ru, Gleb Smirnoff writes: Cy, On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote: C What I'd prefer to see is the following: C C - commit new ipfilter untouched to vendor-sys/ipfilter C - nuke sys/contrib/ipfilter C - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter C C Having ipfilter in one place instead of two (vendor and vendor-sys) makes a C lot more sense. C C I suppose we could put ipfilter's kernel components in sys/netpfil but wha t C about the userland sources? Also see my reply below regarding keeping it i n C contrib. IMO, it is possible to keep a bulk checkout of ipfilter in vendor/ipfilter, but merge kernel files separately to sys/netpfil/ipfilter, and separately merge userland files to appropriate place. C In future imports do: C C - commit newer ipfilter to vendor-sys/ipfilter C - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter C C What's the reason to keep code in contrib? C C The reason to keep ipftilter in contrib is to maintain consistency with C other contributed software such as bind, nvi, sendmail, pf, and a host of C other notable software we don't maintain ourselves. Maintaining consistenc y C with other contributed software should probably be maintained. I'm open to C moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as C long as consistency is maintained across the board. C C Do you think we should put the userland sources also in the same location C or should we maintain a similar separation we do today? I'm open to both C however I'd prefer keeping all vendor software (kernel and userland) in on e C location. The BSD license allows us to put the code into FreeBSD w/o any separation. So the question is: what is more handy to us? What do we actually gain having contrib/ipf, assuming we got vendor branch already? What we lose is: - more complex Makefiles - more complex hacking: edit files in one place, run make in other How is this for a plan? Instead of importing the kernel bits into vendor-sys/ipfilter and the userland bits into vendor/ipfilter, the base tarball should be imported into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We keep the complete tarball imported into one place in the tree. Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and netpfil/ipfilter (for userland bits). We should probably think of moving pf and ipfw into the new subdirectory as well, but that's for a future discussion. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
Cy, On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote: C Unfortunately it doesn't work any more. Here is what svn spit out at me. C C slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter C slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfilte C r/dist@252548 C svn: E205000: Try 'svn help merge' for more information C svn: E205000: Source and target must be different but related branches C svn: E205000: Source and target have no common ancestor: C 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist@252548' and C '.@unspecified' C slippy$ AFAIU, the problem is that current contrib/ipfilter was never merged from vendor/ipfilter. So, actually we are dealing with a first import (from subversion viewpoint), not n-th. What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
In message 20130705084649.gc67...@freebsd.org, Gleb Smirnoff writes: Cy, On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote: C Unfortunately it doesn't work any more. Here is what svn spit out at me. C C slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter C slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfil te C r/dist@252548 C svn: E205000: Try 'svn help merge' for more information C svn: E205000: Source and target must be different but related branches C svn: E205000: Source and target have no common ancestor: C 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist@252548' and C '.@unspecified' C slippy$ AFAIU, the problem is that current contrib/ipfilter was never merged from vendor/ipfilter. So, actually we are dealing with a first import (from subversion viewpoint), not n-th. That's unfortunate. What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter Having ipfilter in one place instead of two (vendor and vendor-sys) makes a lot more sense. I suppose we could put ipfilter's kernel components in sys/netpfil but what about the userland sources? Also see my reply below regarding keeping it in contrib. In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? The reason to keep ipftilter in contrib is to maintain consistency with other contributed software such as bind, nvi, sendmail, pf, and a host of other notable software we don't maintain ourselves. Maintaining consistency with other contributed software should probably be maintained. I'm open to moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as long as consistency is maintained across the board. Do you think we should put the userland sources also in the same location or should we maintain a similar separation we do today? I'm open to both however I'd prefer keeping all vendor software (kernel and userland) in one location. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Ipfilter pre-Vendor Import Issue
Hi, Originally this email was a here is how I'm planning on doing it kind of email but now that svn 1.8 broke the third step I need some help. I've been getting the flattening of the ipfilter vendor branch right and working on the importation of ipfilter 5.1.2 into my own test SVN repo. (Now that we have Darren Reed's permission to use the previous license, I will import 5.1.2). I've prepared the tree by flattening the layout as discussed in 5.3.1 of the developers handbook. It worked until I upgraded my SVN port from 1.7.2 to 1.8. Here are the steps I took and the results of the last failing step. I will also discuss what I believe should be the solution. Given I'm not an SVN expert I need some advice and help. To flatten the ipfilter vendor branch I did the following. This worked before using svn 1.7.2 and continues to work using 1.8. cd $MY_WORK_DIR/vendor/ipfilter for I in */contrib/ipfilter; do ( cd $I svn mv $(svn list) ../.. cd ../.. svn rm contrib svn propdel -R svn:mergeinfo ) done cd $MY_WORK_DIR/vendor-sys/ipfilter for I in */sys/contrib/ipfilter; do ( cd $I svn mv $(svn list) ../../.. cd ../../.. svn rm sys svn propdel -R svn:mergeinfo ) done cd $MY_WORK_DIR svn ci vendor/ipfilter vendor-sys/ipfilter The second step is to turn off keyword expansion as recommended by the developers guide. This worked before under 1.7.2 and continues to work under svn 1.8. cd $MY_WORK_DIR/vendor/ipfilter svn propdel svn:keywords -R . cd $MY_WORK_DIR/vendor-sys/ipfilter svn propdel svn:keywords -R . cd $MY_WORK_DIR svn ci vendor/ipfilter vendor-sys/ipfilter It's the last step of the flattening process discussed in the developers guide that worked under svn 1.7.2 but does not work under svn 1.8. What I planned on doing was this: cd $MY_WORK_DIR/current/contrib/ipfilter svn merge --record-only \ svn+ssh://svn.FreeBSD.org/base/vendor/ipfilter/dist@NNN cd $MY_WORK_DIR/current/sys/contrib/ipfilter svn merge --record-only \ svn+ssh://svn.FreeBSD.org/base/vendor-sys/ipfilter/dist@NNN (Don't worry about the NNN, I will fill that in with the appropriate rev.) Unfortunately it doesn't work any more. Here is what svn spit out at me. slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfilte r/dist@252548 svn: E205000: Try 'svn help merge' for more information svn: E205000: Source and target must be different but related branches svn: E205000: Source and target have no common ancestor: 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist@252548' and '.@unspecified' slippy$ My solution is, for I in `find . -type f`; do svn merge --record-only -r 1:HEAD file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist/$I@252548; done (r252548 is the revision where I turned off keyword expansion for the flattened ipfilter vendor trees.) I'm not a subversion expert so my question is, am I going down the right path here? Or, is there a better way to address the error above? Once I address this I will be able to import the new ipfilter into the vendor and vendor-sys branches (which I managed to get to under svn 1.7.2). To answer the obvious question, I've done svn upgrade and when that didn't help I subsequently used a fresh checkout from my local test SVN repo, so this is not an issue. Any and all help would be appreciated. Thanks for your help. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
