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 yo
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 g
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
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 branc
> > > 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
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":
>
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
Dag-Erling SmЬrgrav 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 she
> > > 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
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
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 co
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 th
> > > 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 t
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 d
> > > 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 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 i
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
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 (
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 goo
> > 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
> > all
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 Clea
> > 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
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
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
> > [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 wou
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
> > > 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
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 "believ
> > 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 se
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
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
> > 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
> > > 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
> > >
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 the
> 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
35 matches
Mail list logo
