Darrel writes:
Also, on my amd64 kernel I had to remove 'device atapicam'.
The failed kernel build might be a bug, perhaps I should file a
report.
As far as I know, this is completely unrelated to
subversion/c(v)sup. Please check for other issues.
Thanks, Matthew- and especially for mentioning to use -F on the first
subsequent run of mergemaster.
svn co http://svn.freebsd.org/base/releng/9.1 src
For ports would it be better to match -fbsd91, like this:
svn co http://svn.freebsd.org/ports/releng/9.1 ports
or can the most recent
Darrel levi...@iglou.com writes:
Thanks, Matthew- and especially for mentioning to use -F on the first
subsequent run of mergemaster.
svn co http://svn.freebsd.org/base/releng/9.1 src
For ports would it be better to match -fbsd91, like this:
svn co
Darrel levi...@iglou.com wrote:
For ports would it be better to match -fbsd91, like this:
svn co http://svn.freebsd.org/ports/releng/9.1 ports
404. There are no branches in the ports, in exactly the same
way that there wasn't a RELENG_9 tag you could use in a ports supfile.
Head is the only
Matthew Seaman matt...@freebsd.org writes:
On 03/09/2012 17:29, Lowell Gilbert wrote:
I'm not sure whether there's any equivalent to tracking RELENG_9 (as
opposed to tracking RELENG_9_1) under the branching scheme being used
with subversion.
stable/9 is the SVN equivalent of RELENG_9
Ah,
Lowell Gilbert writes:
Is anyone working on documenting this for the cutting edge
section of the Handbook? I could take a shot at it myself, but I
likely couldn't produce anything intelligible for beginners (at
least, not before 9.1 is out).
That would be hugely appreciated;
On Mon, 3 Sep 2012, Lowell Gilbert wrote:
Matthew Seaman matt...@freebsd.org writes:
On 03/09/2012 17:29, Lowell Gilbert wrote:
I'm not sure whether there's any equivalent to tracking RELENG_9 (as
opposed to tracking RELENG_9_1) under the branching scheme being used
with subversion.
For ports would it be better to match -fbsd91, like this:
svn co http://svn.freebsd.org/ports/releng/9.1 ports
On 03/09/2012 17:29, Lowell Gilbert wrote:
I'm not sure whether there's any equivalent to tracking RELENG_9 (as
opposed to tracking RELENG_9_1) under the branching scheme being
On 03/09/2012 19:00, Darrel wrote:
Could I then run:
svn co svn://svn.freebsd.org/ports/releng/[ 91 9.1] /usr/ports/
or | and
svn co svn://svn.freebsd.org/ports/stable/9 /usr/ports/ ?
Why don't you try it and see? All you'll get is an error message
essentially saying 'file not found.'
Darrel levi...@iglou.com writes:
For ports would it be better to match -fbsd91, like this:
svn co http://svn.freebsd.org/ports/releng/9.1 ports
On 03/09/2012 17:29, Lowell Gilbert wrote:
I'm not sure whether there's any equivalent to tracking RELENG_9 (as
opposed to tracking RELENG_9_1)
On Mon, 3 Sep 2012, Matthew Seaman wrote:
On 03/09/2012 19:00, Darrel wrote:
Could I then run:
svn co svn://svn.freebsd.org/ports/releng/[ 91 9.1] /usr/ports/
or | and
svn co svn://svn.freebsd.org/ports/stable/9 /usr/ports/ ?
Why don't you try it and see? All you'll get is an error
stable/9 is the SVN equivalent of RELENG_9
src only, understood now. Thanks, Matthew.
Yes. There is never any branching in the ports tree. The latest (i.e.,
head) version is, at any given time, expected to work for all (then)
supported versions of the base system.
This is not a change --
Darrel levi...@iglou.com writes:
On Mon, 3 Sep 2012, Lowell Gilbert wrote:
Matthew Seaman matt...@freebsd.org writes:
On 03/09/2012 17:29, Lowell Gilbert wrote:
I'm not sure whether there's any equivalent to tracking RELENG_9 (as
opposed to tracking RELENG_9_1) under the branching scheme
Is anyone working on documenting this for the cutting edge section of
the Handbook? I could take a shot at it myself, but I likely couldn't
produce anything intelligible for beginners (at least, not before 9.1 is
out).
If you do decide to write a new section, I could possibly offer help
on
Darrel writes:
Next, I will decide whether to keep /usr/ports with portsnap or
move ports to svn as well.
I just did this (ports and docs) and - modulo an error on my
part - it has been remarkably painless. (Make sure you eradicate
all vesitges of c(v)sup activity.)
Next, I will decide whether to keep /usr/ports with portsnap or
move ports to svn as well.
I just did this (ports and docs) and - modulo an error on my
part - it has been remarkably painless. (Make sure you eradicate
all vesitges of c(v)sup activity.
Hello Robert,
Other than
On Mon, 3 Sep 2012, Darrel wrote:
Next, I will decide whether to keep /usr/ports with portsnap or
move ports to svn as well.
I just did this (ports and docs) and - modulo an error on my
part - it has been remarkably painless. (Make sure you eradicate
all vesitges of c(v)sup
17 matches
Mail list logo
