OutbackDingo wrote:
On Fri, 2007-11-09 at 14:43 +0000, Tom Evans wrote:
On Fri, 2007-11-09 at 21:49 +0800, OutbackDingo wrote:
well thats kinda hard to do with CVS, though other revision systems such
as mercurial, bazaar, git and perforce, even subversion do it well,
there is also a mercurial respository for FreeBSD out there some where
On Fri, 2007-11-09 at 05:36 +0000, Aryeh M. Friedman wrote:
2. If yes to #1 how do I setup keeping everything except my modified
code in sync (and if possible to retro activally apply patchs from the
local branch unto the main source tree [/usr/src2])
You won't be able to commit to the BSD repo from your server. I
think you should treat your repo as read only and use cvsup to keep
it up to date. At least that's what I do.
What I meant was how do I keep from clobbering my local changes?
(Nothing like top posting to destroy the thread flow)
OutbackDingo is incorrect. That is the entire purpose of CVS, otherwise
they might as well call it VS..
Your /usr/src will be a checkout of a particular branch of freebsd
(called a working copy). You periodically update your cvs repository
(where you checkout from) with the latest freebsd commits.
When you wish to, you update your working copy from your repository by
issuing a 'cvs up'. This merges changes in the repository into your
local copy, merging in with the local changes.
When you want to see what has changed since you last did a 'cvs up',
issue a 'cvs -n up'.
When you want to see the local modifications in your working copy, issue
a 'cvs diff'.
Read the cvs red-bean book for more info.
http://cvsbook.red-bean.com/cvsbook.html
HTH
Tom
Well I wouldnt say incorrect as i stated it was hard to do. Meaning its
easier to complete these tasks with a different RCS, in my OWN opinion.
So as not to clobber ones changes locally. I didnt say it could not be
done, its simply more difficult to achieve the same result as with other
RCS systems. The reason I sated as more difficult to do, Ive seen quite
a number of times when tracking a vendor branch, that merges had to be
more manually handled because of local changes. This is another of those
"preferences" people get into wars over, Best OS, Browser, RCS etc etc
ok having done this for years here's how it goes.
If you have a private CVS repo mirroring the FreeBSD tree then you can
keep your changes up to date in your "checked out" source tree. but you can generally
not check them in anywhere.
You CAN keep your own special branch (I think it was branch numbers
above 100000 or something, check cvsup docs)
that cvsup will not over write, and you can check in your changes there
but that branch will not automatically update from freebsd.org
so you will need to do branch updates regularly. (and that can be tricky
and time consuming in CVS) otherwise your branch will
get out-of date when compaerd with -current.
usually I just keep my work checked out until I'm ready to feed the changes back
but I take regular diffs and stash them away as 'backups' :-)
This is why we have the perforce repo in addition to CVS.
it is good at doing large branch manipulations, and it is
more feasible to keep your own branch in sync with the branch that is kept up to
date with the CVS tree.
Unfortunatly, we don't give out access to that to 'anybody',
it may be possible to get mercurial to do similar, or if you could get a
'personal use' p4 server you could get the scripts from Peter and see
if you could do the same. I wonder if ther is a way we could broadcast changes
to the p4 'head' branch so that people could keep their own p4 servers
up to date..
etc...
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
