The idea is to support a cache repository (the one copied to a local
machine by CVSup or CTM) transparently. So that the reads from
directory will go from the local cache repository (and won't
overstrain the remote server, and will be fast too), while the commits
and other changes will go
Nate Williams wrote:
The value specified in CVSROOTCACHE is the local path to the cache
repository. All the check-outs, updates, diffs etc. will be obtained
from there. All the check-ins, tagging etc. will go into the master
repository specified by CVSROOT. Naturally, to see these
The value specified in CVSROOTCACHE is the local path to the cache
repository. All the check-outs, updates, diffs etc. will be obtained
from there. All the check-ins, tagging etc. will go into the master
repository specified by CVSROOT. Naturally, to see these changes
in the cache
Yet another idea is to be able to make local commits with committing
them to the central remote repository later.
I'd do the reverse, since the possibility of synchronization problems
are a huge deal. Imagine if someone 'snuck' in and made a commit in
the master tree after your local
so, i am working on building a super-server for me
and several friends to collaborate with on the money front
to put our machine in a colo location, etc.. and still have good
access to networking resources.
as a result, i needed to modify the FreeBSD kernel such
that it will
With the -s option, cvsup will not touch files that it believes are
in sync until they are updated on the server.
^^^
not ?
no, not not. cvsup will not touch files that it believes are in
sync, the operative word here being believes - with -s cvsup will
use the checkout list
Sean Chittenden [EMAIL PROTECTED] writes:
[local commit to file A ]
[different developer commits to file A on master repo]
[commit to file A on master repo]
[cvsup local repo with master repo]
Wouldn't you have to delete A,v before A,v would continue to pick up
future changes?
[local commit to file A ]
[different developer commits to file A on master repo]
[commit to file A on master repo]
[cvsup local repo with master repo]
Wouldn't you have to delete A,v before A,v would continue to pick up
future changes? -sc
No, cvsup would notice that
Hello,
This patch is interesting. To my understanding though, ipfw uses RAW sockets
to communicate with the kernel. Therefore, it might be possible to edit the
ipfw table from within the jail, which may be a bad thing. Just a thought.
Thanks,
--
Mooneer Salem
GPLTrans: http://www.translator.cx/
Sean Chittenden wrote:
It'd be cool to teach CVSup to ignore updating certain files that have
been marked locally as dirty or in flux until they've been
committed through to the master repo. Even better would be to have
CVSup ignore making changes to designated branches (RELENG_5_SEANC).
Sergey Babkin wrote:
Nate Williams wrote:
[ ... CVS cache and cache coherency ... ]
Yet another idea is to be able to make local commits with committing
them to the central remote repository later. Now I have to use RCS
locally for the temporary in-delevopment versions of file. Would
be
The corollary to that would be to teach cvs(1) to commit changes to
the master repo that have been made to the local repo. Version number
sync would be a problem, but it'd be really cool to be able to do
that. With a branch mapping layer (RELENG_5_SEANC - HEAD), people
could actually
Nate Williams wrote:
The other solution to the problem is the P4 route. Making things so
darn effecient that there's little need to have a local mirror. Where
this falls down is when the remote developer doesn't have a 24x7
connection to the main repository. From what I've been told
Yaoping Ruan wrote:
Does any one know the implementation of ktrace in FreeBSD? I would
like to hack the source code and have a relatively easy way to copy
the kernel stack image when a certain of thing happens, such as page
fault. It should work like the breakpoints in gdb. But kernel panic
The other solution to the problem is the P4 route. Making things so
darn effecient that there's little need to have a local mirror. Where
this falls down is when the remote developer doesn't have a 24x7
connection to the main repository. From what I've been told ClearCase
allows for
Nate Williams wrote:
The current version of Perforce has p4proxy which caches
a local copy
of the depot files used.
Does it still require a working net link to the master
repository? When
it was originally released, I remember it being useful for slow links,
but not so good on
/freebsd-current/20030316.freebsd-current
Specifically, search for Jake Burkholder.
Likely, when this is committed, it will be treated as a different
architecture (IMO), rather than Patches to i386. See the recent
PC98 It's ISA!/It's not!/Is too!/Is not!/... discussion for
details as to why.
-- Terry
Mark Tinguely wrote:
Intel x86 hardware allows windows of 4GB of virtual memory even if
you have the PSE-36 and the PAE extensions with more the 4GB of
physical memory. Sound a little like Intel's 64KB windows, but
if I remember correctly, the 4GB does not have to be contiguous.
It would
On Sun, Mar 16, 2003 at 04:32:48PM -0700, Nate Williams wrote:
What is the status of Perforce in the FreeBSD project? Is the issue the
absence of a p4up? Licensing? Inertia?
See the archives for a more thorough discussion, but I believe the
licensing is the biggest issue. If we moved
Nate Williams wrote:
Nate's suggestion covers the version number issue... sort of. It
assumes that the patches will be approved for commit to the main
repo
This is easy to get around, b/c if the commit doesn't happen
successfully on the repo, then the commit fails, and as such it also
Nate's suggestion covers the version number issue... sort of. It
assumes that the patches will be approved for commit to the main
repo
This is easy to get around, b/c if the commit doesn't happen
successfully on the repo, then the commit fails, and as such it also
won't also be
On Sun, Mar 16, 2003 at 02:30:36PM -0800, Mooneer Salem wrote:
Hello,
This patch is interesting. To my understanding though, ipfw uses RAW sockets
to communicate with the kernel. Therefore, it might be possible to edit the
ipfw table from within the jail, which may be a bad thing. Just a
Nate Williams wrote:
I see how you are viewing this: as a means of avoiding a full
CVSup.
I think the reason the cache was wanted was not to avoid the
CVSup, but to allow operations *other than CVSup* to proceed
more quickly?
Having a local 'CVS' tree mirrored already does this.
I see how you are viewing this: as a means of avoiding a full
CVSup.
I think the reason the cache was wanted was not to avoid the
CVSup, but to allow operations *other than CVSup* to proceed
more quickly?
Having a local 'CVS' tree mirrored already does this. However, it's a
Thus spake Terry Lambert [EMAIL PROTECTED]:
Nope. I commit locally as nwilliams, and then I commit on
FreeBSD.org as nate. Then I try to update, and the versions
match, but the tag data in the file itself doesn't.
So Terry has actually been writing code for the FreeBSD project
all these
David Schultz wrote:
Thus spake Terry Lambert [EMAIL PROTECTED]:
Nope. I commit locally as nwilliams, and then I commit on
FreeBSD.org as nate. Then I try to update, and the versions
match, but the tag data in the file itself doesn't.
So Terry has actually been writing code for the
Jail is irrelevant if an attacker can access the kernel.
It sounds like you're looking for a secure solution that UNIX doesn't
even have the capability to implement. The real solution in a BSD
environment would be too elaborate for my taste. It would make
more sense to me to move away from UNIX ;)
Sean Chittenden [EMAIL PROTECTED] writes:
Right, which is what I was trying to suggest a fix for in the first
place: the ability to prevent the loss of work committed to a local
repository when using cvsup to sync repositories with the master repo.
if you *want* to keep the local changes (I
Sergey Babkin [EMAIL PROTECTED] writes:
A similar thing may be achieved by checking the files out from the local
repository and doing any modification command with option -d. But that's
troublesome and inconvenient.
Read the manual page for the shell you're using, with particular
emphasis on
Sean Chittenden [EMAIL PROTECTED] writes:
It'd be cool to teach CVSup to ignore updating certain files that have
been marked locally as dirty or in flux until they've been
committed through to the master repo.
With the -s option, cvsup will not touch files that it believes are in
sync until
It'd be cool to teach CVSup to ignore updating certain files that have
been marked locally as dirty or in flux until they've been
committed through to the master repo.
With the -s option, cvsup will not touch files that it believes are
in sync until they are updated on the server.
^^^
Sean Chittenden [EMAIL PROTECTED] writes:
With the -s option, cvsup will not touch files that it believes are
in sync until they are updated on the server.
^^^
not ?
no, not not. cvsup will not touch files that it believes are in
sync, the operative word here being believes - with -s
:
unix windows,!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
On Mon, Mar 17, 2003 at 12:39:22PM +0300, sergej wrote:
mozno li ustanovit% odnovremenno na odin disk:
unix i windows, i kak jto sdelat%!
Get yourself a copy of the Complete FreeBSD by Greg Lehey,
which covers this subject very well. This question also belongs
to freebsd-questions, not
On Sun, Mar 16, 2003 at 02:30:36PM -0800, Mooneer Salem wrote:
When i was looking at this i was somewhat frustated with
the way suser() doesn't really allow any sort of a context-of-check
to happen easily that i was able to find. ie, was it for a networking
check, filesystem, etc..
On Mon, Mar 17, 2003 at 10:06:27AM +0300, .@babolo.ru wrote:
It is time to invent ping socket and traceroute socket
in addition to tcp, udp, divert so on?
Whilst this might seem nice, actually implementing so that it is
both useful and safe is not easy.
For a ping socket, this is reasonably easy
36 matches
Mail list logo
