dotSoftwaredotDevelopmentdotCustomersdotAbout us
PushOk logoblank
bullet Home
bullet My software
bullet Support
bullet My payments
bullet My info
bullet Subscriptions
bullet Voting
bullet Contact us
fast linksFast Links
news&eventsnews and events

2012-12-21 
Major update of SVN SCC plug-in - versions 1.7.2 are finaly released

2012-12-21 
Major update of SVNCOM version 1.7.2 are finaly released

Lightweight embedded Node.js database with MongoDB API.

Ticket

Search go
PushOk Logo blank
leftTicketright

Checkout wiped out by second checkout

( CVSSCC )
Type: Public Status:Closed Created: 19 May 04 05:00 Updated: 20 May 04 05:00
--> Mike Milvand (user)  at 20 May 04 05:00 writes

Thank you for your answer. We will evaluate your answer.
-----Original Message-----
From: Pushok Software [mailto:support@pushok.com]
Sent: Thursday, May 20, 2004 11:05 AM
To: Mike Milvand (LCL)
Subject: Re: [pst154] Checkout wiped out by second checkout
http://www.pushok.com/tickets_messages.php?id=154
We checked this behavior, and it is really exist. What I can say that
we use CVS during about 4 years and still not have problems with this.
May be when we will know this we will be aware. However I not think
this really important, since it is hard to imagine that this can
occurs during normal work.
So, "cvs edit" functionality which you refer to, work on "per user"
basis. That means that if the _same_ user have files in several local
folders on the same pc (may be on different too) he marked as editor
only for last "cvs edit". When "cvs unedit" or "cvs commit" applied in
one place, user automatically removed from editors list even if he
still "edit" file in other folder. So, this is how CVS designed.
However, I check INET and see that several users want to have that you
want. I.e. track edit not only per user, but "per user per file". Here
the links I found:
http://www.mail-archive.com/bug-cvs@gnu.org/msg00116.html
http://www.geocrawler.com/archives/3/383/1996/11/0/2114292/
As I see some patches for this are available. You can apply them, or
may be you can found patched version. As I understand this is just
some fix on server side.
Few more comments. Please note that if several _users_ edit the same
file all work ok. The case is only when the same user edits the same
file in several folders.
Also, plug-in itself does not implement any CVS functionality, and
just use cvs.exe for all operations. So if you find or compile patched
version or will work with plug-in.
And the last, you should consider is this really problem for you or
not. As I remember SourceSafe it somehow linked to working copy, and
as I remember this cause much more problems. I.e. I think that this is
not bad that CVS works how it works.
--> Igor Pushkov (admin)  at 20 May 04 05:00 writes

We checked this behavior, and it is really exist. What I can say that
we use CVS during about 4 years and still not have problems with this.
May be when we will know this we will be aware. However I not think
this really important, since it is hard to imagine that this can
occurs during normal work.
So, "cvs edit" functionality which you refer to, work on "per user"
basis. That means that if the _same_ user have files in several local
folders on the same pc (may be on different too) he marked as editor
only for last "cvs edit". When "cvs unedit" or "cvs commit" applied in
one place, user automatically removed from editors list even if he
still "edit" file in other folder. So, this is how CVS designed.
However, I check INET and see that several users want to have that you
want. I.e. track edit not only per user, but "per user per file". Here
the links I found:
http://www.mail-archive.com/bug-cvs@gnu.org/msg00116.html
http://www.geocrawler.com/archives/3/383/1996/11/0/2114292/
As I see some patches for this are available. You can apply them, or
may be you can found patched version. As I understand this is just
some fix on server side.
Few more comments. Please note that if several _users_ edit the same
file all work ok. The case is only when the same user edits the same
file in several folders.
Also, plug-in itself does not implement any CVS functionality, and
just use cvs.exe for all operations. So if you find or compile patched
version or will work with plug-in.
And the last, you should consider is this really problem for you or
not. As I remember SourceSafe it somehow linked to working copy, and
as I remember this cause much more problems. I.e. I think that this is
not bad that CVS works how it works.
--> Mike Milvand (user)  at 19 May 04 05:00 writes

Here is a Scenario where I see a problem.

1) I have an existing CVS repository called ABC.

2) I create a new VB project at location (c:\test\ProjectCopy1)

3) I select tools -> PushOK CVS Proxy -> "Create Project from PushOK CVS
..." and I use the ABC Repository

4) I then select tools -> PushOK CVS Proxy -> "Check Out"
and I checkout moduleA.bas

5) Now the CVS repository called ABC contains the entry CVS/fileattr with
the lock or checkout or whatever you call it.

6) I create a new VB project at a different location
(c:\test\ProjectCopy2)

7) I select tools -> PushOK CVS Proxy -> "Create Project from PushOK CVS
..." and I use the ABC Repository again

8) Now the CVS repository called ABC no longer contains the entry
CVS/fileattr. The sandbox at c:\test\ProjectCopy2 has caused it to be
erased.

9) c:\test\ProjectCopy1 still shows it has moduleA.bas checked out, but the
repository does not show this and now others can check it out not knowing
that two people will have the module checked out.

Rate this ticket:
Not useful at all
Partially useful
Useful
Very useful



You are 9542294 visitor since 20 Jan 2003.
639 visitors today and 2 online right now.
blank left to top right blank

© Copyright by PushOk Software, 2003-2024, webmaster@pushok.com