Can i *lock* a file in CVS [message #44492] |
Mon, 03 February 2003 18:40 |
Eclipse User |
|
|
|
Originally posted by: jonathan.brighthaul.com
I've started experimenting with Eclipse and CVS.
From what I gather, when doing an "update" (check in) there is nothing to
prevent other developers
from checking in their version.
Is this true?
If not, how can I enable locking?
|
|
|
Re: Can i *lock* a file in CVS [message #44523 is a reply to message #44492] |
Tue, 04 February 2003 00:06 |
Eclipse User |
|
|
|
Originally posted by: jaimevallori.eresmas.com
Yonatan Taub wrote:
> I've started experimenting with Eclipse and CVS.
> From what I gather, when doing an "update" (check in) there is nothing to
> prevent other developers
> from checking in their version.
>
> Is this true?
> If not, how can I enable locking?
Since it is possible to lock files in CVS, it isn't very usual. CVS will try
to merge conflicting versions of the files and if it can't do this
operation, it will force a manual merge. Anyway, I THINK this feature -file
locking- is not available through the eclipse ide.
The command-line for locking a file would be:
#> cvs admin -l myfile
|
|
|
Re: Can i *lock* a file in CVS [message #44554 is a reply to message #44492] |
Tue, 04 February 2003 02:38 |
Eclipse User |
|
|
|
Originally posted by: maildump.pacbell.net
The idea is that you do not lock an entire file to avoid the problem of
having to unlock files should you be running to the store, getting your hair
done or gunned down in a drive-by. CVS will flag conflicts when two or more
indivduals have updated the same section of code and the frequency of such
collisions is relatively infrequent. Given the sheer number and scope of
projects using CVS as the version control system you can rest assured this
approach is both effective and reliable. I will it mit it does take some
getting use to.
"Yonatan Taub" <jonathan@brighthaul.com> wrote in message
news:b1mbsp$8jv$1@rogue.oti.com...
> I've started experimenting with Eclipse and CVS.
> From what I gather, when doing an "update" (check in) there is nothing to
> prevent other developers
> from checking in their version.
>
> Is this true?
> If not, how can I enable locking?
>
>
|
|
|
|
Re: Can i *lock* a file in CVS [message #589759 is a reply to message #44492] |
Tue, 04 February 2003 00:06 |
Eclipse User |
|
|
|
Originally posted by: jaimevallori.eresmas.com
Yonatan Taub wrote:
> I've started experimenting with Eclipse and CVS.
> From what I gather, when doing an "update" (check in) there is nothing to
> prevent other developers
> from checking in their version.
>
> Is this true?
> If not, how can I enable locking?
Since it is possible to lock files in CVS, it isn't very usual. CVS will try
to merge conflicting versions of the files and if it can't do this
operation, it will force a manual merge. Anyway, I THINK this feature -file
locking- is not available through the eclipse ide.
The command-line for locking a file would be:
#> cvs admin -l myfile
|
|
|
Re: Can i *lock* a file in CVS [message #589771 is a reply to message #44492] |
Tue, 04 February 2003 02:38 |
Eclipse User |
|
|
|
Originally posted by: maildump.pacbell.net
The idea is that you do not lock an entire file to avoid the problem of
having to unlock files should you be running to the store, getting your hair
done or gunned down in a drive-by. CVS will flag conflicts when two or more
indivduals have updated the same section of code and the frequency of such
collisions is relatively infrequent. Given the sheer number and scope of
projects using CVS as the version control system you can rest assured this
approach is both effective and reliable. I will it mit it does take some
getting use to.
"Yonatan Taub" <jonathan@brighthaul.com> wrote in message
news:b1mbsp$8jv$1@rogue.oti.com...
> I've started experimenting with Eclipse and CVS.
> From what I gather, when doing an "update" (check in) there is nothing to
> prevent other developers
> from checking in their version.
>
> Is this true?
> If not, how can I enable locking?
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.02471 seconds