Re: locking entire tree for write

2003-10-14 Thread Paul Sander
>--- Forwarded mail from [EMAIL PROTECTED]

>[ On Tuesday, October 14, 2003 at 13:05:58 (-0400), Derek Robert Price wrote: ]
>> Subject: Re: locking entire tree for write
>>
>> If nobody has any comments on this, I'm going to check in the correction
>> on feature soon.
>>
>> | Correct me if I am wrong, but there is no good reason for the
>> | lock_tree_for_write calls in admin.c, edit.c, and watch.c.  The three
>> | files contain four calls and all are of the form:
>> |
>> | ~lock_tree_for_write
>> | ~start_recursion(...CVS_LOCK_NONE...)
>> | ~Lock_Cleanup
>> |
>> | with no intervening calls.  I believe that in all four locations this
>> | could be replaced with the single call to:
>> |
>> | ~start_recursion(...CVS_LOCK_WRITE...)
>> |
>> | as cvs tag and rtag do and that this would be more efficient, allowing
>> | only a directory at a time to be locked rather than locking an entire
>> | tree for the duration of the entire operations.

>Yes, more efficient, but also more dangerous.

>I don't know (and don't care) about anything to do with 'edit' and
>'watch'.  However in theory even 'tag' and 'rtag' should always first
>lock-for-write the whole module they're oerating on, even for the simple
>case of adding a new tag (some other concurrent user can easily
>encounter problems when trying to use the new tag, or the old tag in the
>case of a rename or delete, or even an existing tag in the case of a
>move).

Believe it or not, I actually agree with Greg on this one.  However, there
are possible implementations that can eliminate the risk.

For example, locking tags in the same what directories are locked and
performing the same kinds of waits prevent users from using tags in
incompatible ways, such as fetching by tag while updating a tag.

Features such as rtag that don't identify in advance the revisions they
act upon can also rely on branch/timestamp pairs to prevent multiple update
problems when users sneak in a commit while rtag processes a different
directory of the same module.

Version tags could also be reimplemented not as symbolic names of specific
revisions but as branch/timestamp pairs.  Branch tags apply to their sprout
points, which can be identified similarly.

It's perhaps too much to ask to reimplement tags as in the last paragraph,
but the first two items are relatively easy to implement.

There has been a lot of research over the years on topics such as "degrees
of isolation" and "lock free algorithms," and CVS could benefit from some
of it.

>--- End of forwarded message from [EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: Preserve time/date on checkin (import) *and* checkout?

2003-10-14 Thread Mark D. Baushke
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Spiro Trikaliotis <[EMAIL PROTECTED]> writes:

> On Wed, Oct 08, 2003 at 09:26:50PM +0200, me myself wrote:
> 
> > I understand I can use 'cvs import' to circumvent storing the actual
> > date/time into the CVS repository but use the file's date and time, but this
> > does not change the behaviour on checkout.
> 
> Noone ever had this problem?
> 
> If it is not possible at all, a simple "it is not possible" would be
> enough for me. :-)

If you are asking if a 'cvs import -d ' will cause the commit time on a
version created by the import to be that of the file being imported,
then the answer is yes.

If you are asking if someone does a 'cvs checkout -D"time-stamp"' before
and after such an import will potentially generate different results as
to what files are checked out due to the presence of imported files with
a timestamp based on the file, then the answer is yes.

The '-D time-stamp' option is not guarenteed to provide the state of the
repository at the 'time-stamp' given, but only the state of any files in
the repository at the time given.

If you do not like this feature, I suppose it might not hurt to ask
nicely if "Ralf S. Engelschall" <[EMAIL PROTECTED]> could consider
making the importinfo script addition able to get the information as to
what flags have been passed and therefore let it be local policy if you
are going to allow 'cvs import -d' commands to be used with your
repository.

Enjoy!
-- Mark

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/jGlf3x41pRYZE/gRAnn6AJ417FKmHe3eeqcx7uLKZxYhV3DH5wCgxkH9
/zcCvXGWxlKn1PuNIajO6SY=
=7jjc
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: CVS refuses to remove (branch) tag

2003-10-14 Thread Derek Robert Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Jaffe wrote:

|I have a user who created a branch tag on a file and wishes to have it
removed. Nothing was committed to the branch. CVS refuses to delete the
tag. Is it because there was no commit to the branch? The message I get
from CVS (version
|1.11.9) is
|cvs tag: Not removing branch tag `cr-1577' from
'/home/cvsroot/internetservices/Ecare/html/care/MICCcontactForm.html,v'.
By default, since 1.11.2, CVS refuses to delete and move branch tags
unless you tell it you know that you are disturbing a branch tag using
the `-B' option to tag or rtag.  This is because disturbing branch tags
is usually a VERY VERY VERY etc. bad idea.  If you are really certain
that the branch has never been used then it shouldn't be a big deal to
delete it.
Derek

- --
~*8^)
Email: [EMAIL PROTECTED]

Get CVS support at !
- --
I don't suffer from stress.  I'm a carrier.
   - Scott Adam's _Dilbert_
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
iD8DBQE/jGALLD1OTBfyMaQRAlGKAJ9vHOSJqqGRA/G8SlRvfa22Xk7qbACgpB2c
/6ZOWWp+3vlljmKtHVSopHA=
=bCyv
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: cvs export end-of-line translation

2003-10-14 Thread Derek Robert Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maarten de Boer wrote:

|Well, but isn't export ment to do this: a special checkout of your
|module destined to be given to third parties. those third parties do not
|necesarily use the same platform as you, when you do the export... And
|using a dos box is no option - the whole process has to be a batch job...
The latest versions of Cygwin will let you run an sshd service on a
Windows box.  Then you can get a secure shell to a Windows box for
running batch jobs.  I think the binary you'll want from cygwin is
`cygrunsrv'.
Derek

- --
~*8^)
Email: [EMAIL PROTECTED]

Get CVS support at !
- --
It's potato, not potatoe.
It's potato, not potatoe.
It's potato, not potatoe...
~  - Bart Simpson on chalkboard, _The Simpsons_
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
iD8DBQE/jGHgLD1OTBfyMaQRAsITAJ9sFVvr0CVXjexbJ6fz2/hTXS79bQCgyP9J
BAYqpdAYZi1Z9eNgyfNvTLE=
=0XcM
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: CVS refuses to remove (branch) tag

2003-10-14 Thread Eric Siegerman
On Tue, Oct 14, 2003 at 12:49:13PM -0700, Mark Jaffe wrote:
> cvs tag: Not removing branch tag `cr-1577' from 
> '/home/cvsroot/internetservices/Ecare/html/care/MICCcontactForm.html,v'.

"cvs -H tag" says:
-B   Allows -F and -d to disturb branch tags.  Use with extreme care.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: Preserve time/date on checkin (import) *and* checkout?

2003-10-14 Thread Larry Jones
Spiro Trikaliotis writes:
> 
> On Wed, Oct 08, 2003 at 09:26:50PM +0200, me myself wrote:
> 
> > I understand I can use 'cvs import' to circumvent storing the actual
> > date/time into the CVS repository but use the file's date and time, but this
> > does not change the behaviour on checkout.
>
> Noone ever had this problem?

I don't recall ever seeing the message and it doesn't seem to be in the
archives at mail.gnu.org, so I think it's safe to say that it never got
sent to the list.

I'm not sure what you're trying to do, but an initial checkout will set
the new working files' timestamps to the timestamps in the repository. 
A subsequent checkout of the same working directory behaves like update
and sets any new or updated files' timestamps to the current time (which
is absolutely necessary for tools like "make" to work correctly).

-Larry Jones

Things are never quite as scary when you've got a best friend. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


CVS refuses to remove (branch) tag

2003-10-14 Thread Mark Jaffe
I have a user who created a branch tag on a file and wishes to have it removed. 
Nothing was committed to the branch. CVS refuses to delete the tag. Is it because 
there was no commit to the branch? The message I get from CVS (version 
1.11.9) is 
cvs tag: Not removing branch tag `cr-1577' from 
'/home/cvsroot/internetservices/Ecare/html/care/MICCcontactForm.html,v'.

=
Mark Jaffe| (408) 972-9638 (home)
Chief Wizard  | (408) 807-1530 (cell)
Computer Wizards  | (425) 795-6421 (FAX)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: Preserve time/date on checkin (import) *and* checkout?

2003-10-14 Thread Spiro Trikaliotis
Hello,

On Wed, Oct 08, 2003 at 09:26:50PM +0200, me myself wrote:

> I understand I can use 'cvs import' to circumvent storing the actual
> date/time into the CVS repository but use the file's date and time, but this
> does not change the behaviour on checkout.

Noone ever had this problem?

If it is not possible at all, a simple "it is not possible" would be enough
for me. :-)

Thanks,
   Spiro.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: locking entire tree for write

2003-10-14 Thread Greg A. Woods
[ On Tuesday, October 14, 2003 at 13:05:58 (-0400), Derek Robert Price wrote: ]
> Subject: Re: locking entire tree for write
>
> If nobody has any comments on this, I'm going to check in the correction
> on feature soon.
>
> | Correct me if I am wrong, but there is no good reason for the
> | lock_tree_for_write calls in admin.c, edit.c, and watch.c.  The three
> | files contain four calls and all are of the form:
> |
> | ~lock_tree_for_write
> | ~start_recursion(...CVS_LOCK_NONE...)
> | ~Lock_Cleanup
> |
> | with no intervening calls.  I believe that in all four locations this
> | could be replaced with the single call to:
> |
> | ~start_recursion(...CVS_LOCK_WRITE...)
> |
> | as cvs tag and rtag do and that this would be more efficient, allowing
> | only a directory at a time to be locked rather than locking an entire
> | tree for the duration of the entire operations.

Yes, more efficient, but also more dangerous.

I don't know (and don't care) about anything to do with 'edit' and
'watch'.  However in theory even 'tag' and 'rtag' should always first
lock-for-write the whole module they're oerating on, even for the simple
case of adding a new tag (some other concurrent user can easily
encounter problems when trying to use the new tag, or the old tag in the
case of a rename or delete, or even an existing tag in the case of a
move).

For "cvs admin" there are many operations which won't leave the module
in an inconsistent state (w.r.t. other CVS readers) while they are still
processing, however it's very difficult to reliably predict which
operations are safe and which are not so 

Without locking the whole module we're relying on the fact that users
will recognize when they get an inconsistent tree and be able to "fix"
their working directory.

If I remember correctly previous discussions on this issue revolved
around the fact that tagging is often a frequent operation and tagging
of large trees should not need to halt all other operations since users
are generally experienced enough to recognize any problems that might
arise.  However "cvs admin" operations are normally quite uncommon and
given the range of possible things 'admin' can do it is generally better
to be safe than sorry and to always lock the whole module for write
before beginning any operation.

I.e.  "we" as a community have in the past agreed that for 'tag' and
'rtag' the benefits of per-directory locking outweigh the risks, but
that is not necessarily the case with 'admin'.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCPRoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: locking entire tree for write

2003-10-14 Thread Derek Robert Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If nobody has any comments on this, I'm going to check in the correction
on feature soon.
Derek

Derek Robert Price wrote:

| Correct me if I am wrong, but there is no good reason for the
| lock_tree_for_write calls in admin.c, edit.c, and watch.c.  The three
| files contain four calls and all are of the form:
|
| ~lock_tree_for_write
| ~start_recursion(...CVS_LOCK_NONE...)
| ~Lock_Cleanup
|
| with no intervening calls.  I believe that in all four locations this
| could be replaced with the single call to:
|
| ~start_recursion(...CVS_LOCK_WRITE...)
|
| as cvs tag and rtag do and that this would be more efficient, allowing
| only a directory at a time to be locked rather than locking an entire
| tree for the duration of the entire operations.
|
| Just wanted to run this by the list before I changed those calls on
stable.
|
| Derek
- --
~*8^)
Email: [EMAIL PROTECTED]

Get CVS support at !
- --
The Pledge of Allegiance does not end with "Hail Satan".
The Pledge of Allegiance does not end with "Hail Satan".
The Pledge of Allegiance does not end with "Hail Satan"...
~  - Bart Simpson on chalkboard, _The Simpsons_
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
iD8DBQE/jCz1LD1OTBfyMaQRAifIAJ4oOulFxl8WXw/4W88Ilb1PrjryrACfdAsc
00FG7P8eqKRos+7AlBX9X6E=
=kGBj
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: cvs export end-of-line translation

2003-10-14 Thread Fabian Cenedese
Hi

As for checking out with different line endings: I haven't tried this but you
could use a windows cvs.exe and run it with wine on *ix, that may give
you DOS-endings even on *ix.

bye   Fabi




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


Re: CVS Client on Mac OS 9.1 & CVS Server on Linux 9.1...

2003-10-14 Thread Gopi Krishna Chebiyyam
Thank you Mr Mark.
I think I have to now think of renaming the files that contain /.
 
Best Regards,
Gopi Krishna"Mark D. Baushke" <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-Hash: SHA1Gopi Krishna Chebiyyam <[EMAIL PROTECTED]>writes:> Dear All,> My CVS Server runs on Linux 9.1 and the CVS Client(MacCVSPro) on> Macintosh OS 9.1.> Whereas CVS does not allow special characters like /(fwd slash) in file> names, Macintosh does allow.> Because of this I am not able to add files whose names contain / to the> CVS.> Could anybody suggest how to accomplish this? In other words is it> possible to configure CVS server such that it would allow / in file names.No. cvs considers that / is always a path element separator on a Linuxserver.-- Mark-BEGIN PGP SIGNATURE-Version: GnuPG v1.2.3 (FreeBSD)iD8DBQE/i5Tp3x41pRYZE/gRAoKUAKChMyHuLIaTcv7hxEBUOfoCb4WcTACeN/+GAEKRnoLDrYPGP/LciRRrnSA==U/Da-END PGP
 SIGNATURE-
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs