> |> Also, commitids should be cached at commit time as well as when
> |> they are found in RCS files. CVS started doing this on tag
> |> creation for other branches and tags a few releases back It's
> |> silly to wait for the first update to insert them into val-tags -
> |> it only triggers an u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frank Hemer wrote:
|> | Ooops, I think I'm too fast;-) I have just finished adding
|> '.trunk' | as a trunk-branch substitution, 'cause I happened to
|> note that this | fits perfectly into my patch. I have already
|> used the above | mentioned splittin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frank Hemer wrote:
|>> | If tags with '@' at the begining are used they're added in
|>> the | cvsnt way (I remember I wrote cvsnt wouldn't cache them
|>> but I was | wrong). If the .commitid is used, they're cached as
|>> | '.commitid.xxx', but this co
> > | If tags with '@' at the begining are used they're added in the
> > | cvsnt way (I remember I wrote cvsnt wouldn't cache them but I was
> > | wrong). If the .commitid is used, they're cached as
> > | '.commitid.xxx', but this could be changed as you suggested.
> >
> > I think this would be a g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Meyering <[EMAIL PROTECTED]> writes:
> > Hmmm... I wonder if it is possible to come up with a sanity.sh test case
> > for this one?
>
> I considered it but, dismissed it as infeasible.
> Of course, I would be happy to be proved wrong.
>
> It mig
Hello,
It looks like no version of CVS detects the write failure
caused by this sort of command:
$ cvs -Q up -p README > /dev/full
$
It should do something like this instead:
$ ./cvs -Q up -p README > /dev/full
cvs [update aborted]: write error: No space left on device
[Exit 1]
I've
David writes:
>
> I've seen an old issue (#127), related to this error/bug, but it still
> happens in the current stable release.
>
> Has it been forgotten or something?
No, it's just a very big job to fix (the entire watch/edit function
needs to be redesigned while still remaining backward com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frank Hemer wrote:
|> The patch looks pretty good. It's pretty close to what I am
|> doing, except I am splitting tags with operators (.word) on the
|> `.' and then processing the resulting list an element at a time.
|> Thus .prev can be implemented fo
> | Ooops, I think I'm too fast;-) I have just finished adding '.trunk'
> | as a trunk-branch substitution, 'cause I happened to note that this
> | fits perfectly into my patch. I have already used the above
> | mentioned splitting - so now '.prev' might even be added more than
> | once and works p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frank Hemer wrote:
| On Saturday 26 February 2005 21:06, Derek Price wrote:
|
|> Frank Hemer wrote: | On Saturday 26 February 2005 00:27, Derek
|> Price wrote: |> Frank Hemer wrote: |> I was just glancing at that
|> patch and I |> think I can implement
> The patch looks pretty good. It's pretty close to what I am doing,
> except I am splitting tags with operators (.word) on the `.' and then
> processing the resulting list an element at a time. Thus .prev can be
> implemented for each and every revision specification type in a single
> location
Using the diff command is no option, because it uses E responses instead of
sending the file content. This causes major troubles with non-ASCII-characters.
--
Best regards,
Thomas Singer
_
smartcvs.com
Jim.Hyslop schrieb:
Thomas Singer wrote:
We've encountered a problem with GNU CVS 1.1
You're invited to download a free copy of Uttam Narsu's
SCM Best Practices white paper courtesy of AccuRev.
Uttam Narsu is a former Forrester and GIGA SCM analyst. The white paper
has received fabulous feedback and, as a courtesy, we thought it might
be of interest to the gnu.cvs.bug community.
T
> Hmmm... I wonder if it is possible to come up with a sanity.sh test case
> for this one?
I considered it but, dismissed it as infeasible.
Of course, I would be happy to be proved wrong.
It might work to use a tool like subterfugue, where you could presumably
cause to fail the first write after
Thomas Singer wrote:
> We've encountered a problem with GNU CVS 1.12.9. Please see
> the following log.
[...]
> CVSNT 2.0.58d behaves correctly, it keeps the editors information.
>
> What request SmartCVS should send, so GNU CVS 1.12.9 just
> sends the original
> content of the file without des
Hi,
I've seen an old issue (#127), related to this error/bug, but it still
happens in the current stable release.
Has it been forgotten or something?
TIA
--
David Santiago
[EMAIL PROTECTED]
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Meyering <[EMAIL PROTECTED]> writes:
> "Mark D. Baushke" <[EMAIL PROTECTED]> wrote:
> > Your patch looks good to me. Go ahead and commit it.
>
> I've done so on the trunk.
> cvs1-11-x-branch too?
Yes, that would be good.
Hmmm... I wonder if it
"Mark D. Baushke" <[EMAIL PROTECTED]> wrote:
> Your patch looks good to me. Go ahead and commit it.
I've done so on the trunk.
cvs1-11-x-branch too?
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
18 matches
Mail list logo
