Re: questions on development(7)

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... 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

_______________________________________________
freebsd-hackers_at_freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_at_freebsd.org"