Terry Lambert wrote:
Sergey Babkin wrote:
Terry Lambert wrote:
# OK, let's suppose that our changes are finally complete, and nobody
# else has committed any other changes in between
cvs ci
Suppose someone has? If you are so out of touch with the net you
need a cache,
Terry Lambert wrote:
Sergey Babkin wrote:
# OK, let's suppose that our changes are finally complete, and nobody
# else has committed any other changes in between
cvs ci
Suppose someone has? If you are so out of touch with the net you
need a cache, you are probably going to get a
Sergey Babkin wrote:
Terry Lambert wrote:
# OK, let's suppose that our changes are finally complete, and nobody
# else has committed any other changes in between
cvs ci
Suppose someone has? If you are so out of touch with the net you
need a cache, you are probably going to get a
Nate Williams wrote:
That's the plan for the next stage, provided that the first stage
goes well. I'm yet to play with CVSup and see if it can be
integrated there (as with system()) easily without making a lot
of changes to CVS itself. Otherwise I'm aftarid it's going to
be a large
That's the plan for the next stage, provided that the first stage
goes well. I'm yet to play with CVSup and see if it can be
integrated there (as with system()) easily without making a lot
of changes to CVS itself. Otherwise I'm aftarid it's going to
be a large amount of work to
Terry Lambert wrote:
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
Nate Williams wrote:
It gets handled in the same way as now: I believe, CVS checks
whether the checked-out version matches the top of the branch,
and if it does not then it refuses to commit and requires you
to make an update. So the same thing can be done for a local branch:
check
It gets handled in the same way as now: I believe, CVS checks
whether the checked-out version matches the top of the branch,
and if it does not then it refuses to commit and requires you
to make an update. So the same thing can be done for a local branch:
check that its base version
Sergey Babkin wrote:
Terry Lambert wrote:
Not really possible, without CVSup coming onto a vendor branch instead
Actually, I was thinking of the opposite: doing all the changes
on a vendor branch (or in some separate local repository altogether),
then merging them into the main branch.
Dag-Erling Smrgrav wrote:
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
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
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
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
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
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
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
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
Hi all,
I've been planning to send this message to the developers mailing
list, but it has mysteriously disappeared (and I haven't found
yet its replacement). So here it goes.
The idea is to support a cache repository (the one copied to a local machine
by CVSup or CTM) transparently. So that the
36 matches
Mail list logo
