TortoiseCVS

> Anyway, to my question.  Simply put, when I commit a file or group 
> thereof, TortoiseCVS seems to automatically do an update on the files 
> immediately after the commit.  Can I turn this off or disable it?

If you don't want to use pageant, you may have to enter your SSH password
multiple times for each TCVS operation. The "update" is performed to work
around a bug in CVS (CVS forgets to update a file's timestamp in CVS/Entries
when committing a "modified" file of which only the filestamp has changed).

-Hartmut

Garrett wrote:

> Hello everybody!
> First time poster.
>
> when I go to commit my change, I want tortoise to let me know if 
> someone else has done a commit since the last time I retrieve the file 
> from the repository.
> Is this possible?

CVS -> Update Special -> Simulate update

> the problem we are having is as follows:
>
> I update to a new version of file FOO.
> The a developer commits some changes.
> Then I commit some changes.
>
> the file in my sandbox will now contain my changes and the latest 
> changes from the repository, which could break the build. Like if the 
> first one changed a variable name that I used for my change. 


You should always update your entire sandbox before committing anything. 
Otherwise you can never be sure that your changes do not break the build.

-Torsten

Garrett wrote:

>>
>>> the problem we are having is as follows:
>>>
>>> I update to a new version of file FOO.
>>> The a developer commits some changes.
>>> Then I commit some changes.
>>>
>>> the file in my sandbox will now contain my changes and the latest 
>>> changes from the repository, which could break the build. Like if 
>>> the first one changed a variable name that I used for my change. 
>>
>>
> my bad,
> I said: Then I commit some changes.
> I meant: Then I Update some changes.

How does this break the build?

-Torsten

"Garrett" asked:


> when I go to commit my change, I want tortoise to let me know if someone
> else has done a commit since the last time I retrieve the file from the
> repository. Is this possible?

well, no.

"That's the way we've always done it"

Seems that the guys who wrote CVS, way back when, decided that a develper
should UPDATE *before* COMMIT

You must understand, unix developers are a very "tradition bound" lot.

Anyway, you just need to get in the habit of doing an UPDATE than a COMMIT
and CVS will work as "designed".

Walter

But I could do an update, get all the new stuff then commit.
but if the person who committed before me removed a variable I use, the 
build would be broke.
which is why I would rather it said "whoa.. someone changed this since 
you checked it out. would you like to see a diff?"
I was just wondering if there was a way to do that.

phpWalter wrote:

>"Garrett" asked:
>
>
>  
>
>>when I go to commit my change, I want tortoise to let me know if someone
>>else has done a commit since the last time I retrieve the file from the
>>repository. Is this possible?
>>    
>>
>
>well, no.
>
>"That's the way we've always done it"
>
>Seems that the guys who wrote CVS, way back when, decided that a develper
>should UPDATE *before* COMMIT
>
>You must understand, unix developers are a very "tradition bound" lot.
>
>Anyway, you just need to get in the habit of doing an UPDATE than a COMMIT
>and CVS will work as "designed".
>
>Walter
>
>
>  
>


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.298 / Virus Database: 265.6.5 - Release Date: 12/26/2004

Garrett wrote:

> But I could do an update, get all the new stuff then commit.
> but if the person who committed before me removed a variable I use, 
> the build would be broke.
> which is why I would rather it said "whoa.. someone changed this since 
> you checked it out. would you like to see a diff?"
> I was just wondering if there was a way to do that.

It does.  It says something to the effect of that, along the lines of 
"Up to date check failed".

-- 
Glen Starrett

The only time I see that is if two developers changed the same line, 
which is different.
clarification

Lets say developer A removes a CONST, but developer b uses that CONST.  
The update would not know that the build is broken. which is what I 
would expect, I just want it to tell me if the file was touched since my 
last update. and let me diff

Garrett

Glen Starrett wrote:

> Garrett wrote:
>
>> But I could do an update, get all the new stuff then commit.
>> but if the person who committed before me removed a variable I use, 
>> the build would be broke.
>> which is why I would rather it said "whoa.. someone changed this 
>> since you checked it out. would you like to see a diff?"
>> I was just wondering if there was a way to do that.
>
>
> It does.  It says something to the effect of that, along the lines of 
> "Up to date check failed".
>


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.298 / Virus Database: 265.6.5 - Release Date: 12/26/2004

Quoting Garrett <garrett_hcg@...>:

> ahhh, however if the build fails I now have a file with both changes in
> it, and I can't go back to a version of the file before I did an update=
.
> Unless I keep a second set of directories.
> Is this the way thing are normally done?
> as it stands now, if I need to do an update, I go into history, get the
> most recent check in, and then do a diff. If I just do a diff, it diffs
> between my current file, and the version I checked out from, not the
> most recent.
>
> so if I have 1.3, and another developer does a commit, making the file
> version 1.4. Now I got to the menu and chose 'CVS Diff' it will diff th=
e
> file I am working on with version 1.3 NOT 1.4...which is what I want.
>

First, if you you and another developer are working on the same functiona=
lity
(or related functionality) in the same file at the same time, you have a
communication problem.  Fix that before addressing anything else.

However, given that mistakes do happen sometimes, there are a couple ways=
 to
approach this.

1.  The paranoid option.  Grab a clean copy off the HEAD of the file(s) i=
n
question.  Your modified file will be copied to a new file with same name
prefixed by ".#" and suffixed by ".[cvs version of the file you were edit=
ing]".
 Now you will have both the latest version and your editied copy locally =
making
it easy to do a diff between the two without polluting your changes with
someone elses.

2.  The more standard option. Just update and do the merge like normal an=
d then
do a diff against the head.  That will show your changes, combined with t=
he
merged changes, against the latest version.  This is usually what you wan=
t
unless you are being really paranoid (which, I'll admit, happens to me fr=
om
time to time).


> I don't mean to be difficult, I just get the feeling I am not using the
> tool correctly.
>

You're not being difficult.  Just trying to get clarification which is pe=
rfectly
legitimate.  I hope I provided it.

Jake

> Garrett
>
> Jacob Kjome wrote:
>
> >Quoting Garrett <garrett_hcg@...>:
> >
> >
> >
> >>But I could do an update, get all the new stuff then commit.
> >>but if the person who committed before me removed a variable I use, t=
he
> >>build would be broke.
> >>which is why I would rather it said "whoa.. someone changed this sinc=
e
> >>you checked it out. would you like to see a diff?"
> >>I was just wondering if there was a way to do that.
> >>
> >>
> >>
> >
> >That's why you update, merge, and then do a test build to make sure
> everything
> >works before you check in.
> >
> >Jake
> >
> >
> >
> >
> >>phpWalter wrote:
> >>
> >>
> >>
> >>>"Garrett" asked:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>when I go to commit my change, I want tortoise to let me know if so=
meone
> >>>>else has done a commit since the last time I retrieve the file from=
 the
> >>>>repository. Is this possible?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>well, no.
> >>>
> >>>"That's the way we've always done it"
> >>>
> >>>Seems that the guys who wrote CVS, way back when, decided that a dev=
elper
> >>>should UPDATE *before* COMMIT
> >>>
> >>>You must understand, unix developers are a very "tradition bound" lo=
t.
> >>>
> >>>Anyway, you just need to get in the habit of doing an UPDATE than a =
COMMIT
> >>>and CVS will work as "designed".
> >>>
> >>>Walter
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>No virus found in this outgoing message.
> >>Checked by AVG Anti-Virus.
> >>Version: 7.0.298 / Virus Database: 265.6.5 - Release Date: 12/26/2004
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>SF email is sponsored by - The IT Product Guide
> >>Read honest & candid reviews on hundreds of IT Products from real use=
rs.
> >>Discover which products truly live up to the hype. Start reading now.
> >>http://productguide.itmanagersjournal.com/
> >>_______________________________________________
> >>tortoisecvs-users mailing list
> >>tortoisecvs-users@...
> >>https://lists.sourceforge.net/lists/listinfo/tortoisecvs-users
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.298 / Virus Database: 265.6.5 - Release Date: 12/26/2004
>

Jacob Kjome wrote:

>Quoting Garrett <garrett_hcg@...>:
>
>  
>
>>so if I have 1.3, and another developer does a commit, making the file
>>version 1.4. Now I got to the menu and chose 'CVS Diff' it will diff the
>>file I am working on with version 1.3 NOT 1.4...which is what I want.
>>    
>>
>
>First, if you you and another developer are working on the same functionality
>(or related functionality) in the same file at the same time, you have a
>communication problem.  Fix that before addressing anything else.
>
>However, given that mistakes do happen sometimes, there are a couple ways to
>approach this.
>
>1.  The paranoid option.  Grab a clean copy off the HEAD of the file(s) in
>question.  Your modified file will be copied to a new file with same name
>prefixed by ".#" and suffixed by ".[cvs version of the file you were editing]".
> Now you will have both the latest version and your editied copy locally making
>it easy to do a diff between the two without polluting your changes with
>someone elses.
>
>2.  The more standard option. Just update and do the merge like normal and then
>do a diff against the head.  That will show your changes, combined with the
>merged changes, against the latest version.  This is usually what you want
>unless you are being really paranoid (which, I'll admit, happens to me from
>time to time).
>  
>
There's a 3rd and 4th option (and variations of course):

3.  Do a update special, simulated update.  That will tell you the list 
of files that would be updated, and you can diff them from sandbox to 
HEAD to see what has changed in the file (very similar to option 2, but 
happens before any of your sandbox is changed).

4.  Use a mailer program to notify the devs on the team when commits 
happen, preferably one that either includes a diff or a hyperlink to a 
ViewCVS (or similar) diff page.  Then you can monitor files that you 
might be dependent on.  Still depends on the human factor.

In general it's best practice to update, test locally, then commit.  
Sometimes subtle things will still creep in.  There is no substitute for 
good developer team communication.

If this type of thing happens often, then you should investigate using 
branches instead of everyone committing to HEAD.  That way, each dev 
would only update HEAD when they have a function to deliver.  There are 
a number of strategies for that as well, fortunately CVSNT takes a lot 
of the work out of using branches (see "Mergepoints" for more 
information on that, http://www.cvsnt.org/wiki/MergePoint).

Regards,

-- 
Glen Starrett

Daniel Barbato wrote:

> I've recently installed cvs on a linux server and managed to get it to 
> authorize itself against a windows 2003 active domain server so that 
> domain users can check in and out without having to manage another set 
> of users and passwords.
>
[...]

> My linux server has cvs 1.12.10 installed, and I'm using tortoiseCVS 
> 1.8.8

I recommend that you install CVSNT on the Linux box and use the SSPI 
protocol. We do this where I work (the AD server also runs Win2003)

-Torsten

>> I think that this approach is wrong. Such a setting works fine if all
>> users use TortoiseCVS *with the correct setting*, but breaks as soon as
>> you have users using the command line or WinCVS, or users not running
>> Windows.

You are quite right. (It really should be done at the server...)

-Nick






Internet
torsten@... - 22/12/2004 21:16


Sent by:    tortoisecvs-users-admin@...



To:    tortoisecvs-users

cc:


Subject:    Re: [TortoiseCVS] Checking out binary files as readonly


nick.minutello@... wrote:

[Replying to the list]

>
>
>>>Only by manually setting "cvs watch on" for only binary files.
>>>
>>>
>
>Ok, we could write a script that went through and ran a "cvs watch" on
each
>binary file...
>
>It would be nice to have a TortoiseCVS setting ("Check out binary files as
>readonly")
>
I think that this approach is wrong. Such a setting works fine if all
users use TortoiseCVS *with the correct setting*, but breaks as soon as
you have users using the command line or WinCVS, or users not running
Windows.

-Torsten

(See attached file: C.htm)

This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet 
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the 
United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority.

No matter how much I love TortoiseCVS, I would like to unsubscribe from the
mailing list... How may I do that ?
Sorry to sound like a noob, but I didn't find an unsuscribe message in the
mails, neither did I find anything on the website.
Thanks in advance !
David.

Hi,

I have the same request...I LOVE Tortoise but i'd like to unsubscribe!

How do we do that??

Thanks
  ----- Original Message -----=20
  From: David Pierron=20
  To: 'tortoisecvs-users'=20
  Sent: Thursday, December 23, 2004 10:10 AM
  Subject: [TortoiseCVS] unsubscribe


  No matter how much I love TortoiseCVS, I would like to unsubscribe =
from the mailing list... How may I do that ?
  Sorry to sound like a noob, but I didn't find an unsuscribe message in =
the mails, neither did I find anything on the website.
  Thanks in advance !
  David.

Go to http://sourceforge.net/projects/tortoisecvs/ -> Lists

-Hartmut


________________________________

	From: tortoisecvs-users-admin@...
[mailto:tortoisecvs-users-admin@...] On Behalf Of sfleury
	Sent: Thursday, December 23, 2004 10:20 AM
	To: David Pierron; 'tortoisecvs-users'
	Subject: [TortoiseCVS] unsubscribe
	
	
	Hi,
	 
	I have the same request...I LOVE Tortoise but i'd like to
unsubscribe!
	 
	How do we do that??
	 
	Thanks

		----- Original Message ----- 
		From: David Pierron <mailto:david.pierron@...>  
		To: 'tortoisecvs-users'
<mailto:tortoisecvs-users@...>  
		Sent: Thursday, December 23, 2004 10:10 AM
		Subject: [TortoiseCVS] unsubscribe

		No matter how much I love TortoiseCVS, I would like to
unsubscribe from the mailing list... How may I do that ?
		Sorry to sound like a noob, but I didn't find an unsuscribe
message in the mails, neither did I find anything on the website.
		Thanks in advance !
		David.

sfleury wrote:

> Hi,
>  
> I have the same request...I LOVE Tortoise but i'd like to unsubscribe!


http://lists.sourceforge.net/lists/listinfo/tortoisecvs-users

-Torsten

Walter Torres wrote:

>Changing the name of files will 'break' version history.  Checking out an
>old date or tag of the repository is almost guaranteed to give you broken
>code. Requiring developers to move code from one file to another
>guarantees that old tags and dates will work correctly every time.
>
>The CVS repository maintains all the version information in the ,v files. 
>So, if you move an entire module from within a module to it's own
>position, or move/rename files with *no* (zero) dependencies on other
>files, this will work without breaking previous versions.
>
>Because all the history is stored in the ,v files, CVS would need to be
>seriously rearchitected to store 'old filenames' and 'old module paths',
>and would need to do significant extra processing to trace back through
>the moves/renames in the repository every time someone asked for an old
>version.
>
>I really don't believe that the CVS core developers will do such a dubious
>amount of extra processing.  Of course, the CVS-NT developers have done
>some dubious things with their fork in the past, which is one of many
>reasons why large projects don't use it.
>
This is exactly what the CVSNT maintainer has chosen to do. And it is 
this rename capability that we intend to use in a future TortoiseCVS 
rename command.

-Torsten