fwiw, I've never had to manually remove the read-only flag on any files I
check out from SourceSafe. They're supposed to be cleared upon checkout.
Also, I've never had SourceSafe setup to remove local files. That's just too
scary imo <g>
In SourceSafe, stand-alone version (I don't use VS2005 for anything real yet
but I'm using SS2005 with VB6), there's Tools/Options and there's a 'Local
Files' tab. On that tab, there are 2 options for deleting local files. One
says "Remove Local Copy after Add or Checkin" and the other says "Remove
Local Copy after delete". Both are cleared here and SourceSafe never removes
my local files. The checkbox right below those says "Use Read-Only flag for
files that are not checked out". That one's checked here (has been since
VSS6 was first released)
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Freeware 4 color Gradient Frame? http://www.vbsight.com/GradFrameCTL.htm
Thanks for your reply. This issue, however, isn't with files that are
checked out, but rather with files that are NOT checked out.
Scenario (this is one of many valid scenarios for this case): Your co-worker
has a file checked out, and you want to make your own edit to it (assume VSS
is configured to disallow multiple checkouts). While you could ask your
co-worker to check it in so you can get the lock, it's quicker and easier
just to flip the Read-Only flag on the file and make your edits, merging
them back in at a later date (e.g., by saving off a copy of your edits,
getting your coworkers changes once they are checked in, and diffing the
two).
Let's say that during the period of you making your edits, you do a Get
Latest Version on the folder containing the file. You don't want to lose
your changes, so what do you do? The only two choices VSS 2005 presents are
to check it out (which is a non-choice in this case because it is already
checked out by someone else) or to overwrite from the checked-in version (in
which case you'd lose your edits). The third option, which is to leave the
file as-is, has been removed (this has *always* been in VSS, as long as I've
been using it).
My settings for the checkboxes you mention are the same as yours (and have
not changed in years).
--Erik Bailey
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:u2MUKkX...@TK2MSFTNGP12.phx.gbl...
I have the same situation as Erik. But in my case, I use de "Make writable"
option in the "Get Latest Version" dialog box.
I mostly use VB 6 and it's a real pain to have your VBP file in Read-Only
mode. VBP files do not need to be changed manually very often (my nigthly
build system does the modifications to the files).
If I would check out VBP files and forget to do "Undo Check Out", my nightly
build would not be able to complete successfully.
I've been using VSS since version 5 for almost 10 years now... the last 2
weeks have been a real pain because the "Keep this file" option is now
grayed out.
Are there any options I should be aware of to get back the old
functionality.
Thanks
"Erik Bailey" <ebaileyREV...@org.ihi> a écrit dans le message de
I'm sure someone with more SS experience (I have plenty of "basic" SS
experience, just none with the 'nitty gritty' details).
The way I do this kind of thing: (and I do it alot since I take work home)
I check out the entire project
Copy all files to a memory stick
take them home for modification
When I bring them back, normally, I just copy the files right over the ones
I've checked out (all except *.scc files). When they're checked back in,
they have all of my "home-work" changes intact.
I rare cases, with the IDE open and files still checked out, I'll open the
homework in Notepad and manually copy/paste into my project. I can't
remember the details about why I had to do it this way a couple of times.
Mostly, it's just check-out, paste modified files, check-in.
> I've recently upgraded to VSS 2005 from 6.0d and have noticed a
> significant change in behavior that I haven't seen discussed in these
> forums: The ability to keep a local writable version of a file seems to
> have been removed.
>
> If I remove the Read-Only flag from a file and make modifications to it,
> VSS 6.0 used to give me three options: keep the file, check it out, or
> replace from VSS. Usually the first option was what I wanted. VSS 2005
> will no longer allow me to select this option (it is grayed out on the
> dialog box). (see attached screenshot, if attachments work in this
> newsgroup)
>
> Examples of why this is valuable are editing local copies of web.config
> files without affecting the master, or prototyping a change on a file that
> someone else has checked out (we disallow multiple checkouts). In both of
> these cases, the two options provided by VSS 2005 are inappropriate.
>
> How can I return to the old behavior? Is there a setting that I missed
> that I need to change? (I looked pretty closely, but might have missed
> something)
Try going to the Options, Local Files tab, and selecting a different choice
for "Replace writable files". Merge is probably your best bet, but maybe
also Skip?
--
Andrew
Keeping local files writable (not checked out) and doing Get on them is a
bad idea, if you don't know what you're doing.
With VSS6, when you decide to checkout that file you'll be prompted to:
leave local file, or replace it with server content.
Naturally, you'll want your changes, so you'll go with "leave local file".
What happens is that you're actually checking out latest version in the
database, but keeping the content of the local file, which may be an old
version. When you're going to checkin, there will be no merge, and you'll
overwrite other user's changes. Here is a scenario (taken from another
customer's report)
> > Foo.cls was on Version 30 in VSS, and when person X did a checkin,
> > creating Version 31, they had actually checked in Version 25 (Not sure
> > if this was due to a bad history call, copy and pasting older code that
> > was stored outside of the repository, or whatever).
> In general, this can happen if some developer has version 25, makes the
> file read-write to make some changes, checks out the file without doing a
> get (without realizing that in the database there is a newer version, and
> he's actually checking out version 30, but he will still have on disk a
> file with version 25 content), then he checks in, thinking he'll checkin
> his changes. In this case there will be no merge (because he checked out
> latest version), and the result is that version 31 will be created with
> the content of version 25 (plus his changes, if he had any).
Anyway, in VSS2005, the suggested option is to use "Checkout the file and
keep the local changes" (checkout local version) instead of "Leave the
file".
If you really don't have any changes in that file, and don't plan to have
any, you can either replace the file with the version from VSS, or undo the
checkout later.
If this is not what you want, when doing the Get, you can click the Advanced
button in the Get Options dialog and select "Replace Writable"==Skip.
--
Alin Constantin
This posting is provided "AS IS" with no warranties, and confers no rights.
"Erik Bailey" <ebaileyREV...@org.ihi> wrote in message
news:OU6oXHXB...@TK2MSFTNGP09.phx.gbl...
> Hi --
>
> I've recently upgraded to VSS 2005 from 6.0d and have noticed a
> significant change in behavior that I haven't seen discussed in these
> forums: The ability to keep a local writable version of a file seems to
> have been removed.
>
> If I remove the Read-Only flag from a file and make modifications to it,
> VSS 6.0 used to give me three options: keep the file, check it out, or
> replace from VSS. Usually the first option was what I wanted. VSS 2005
> will no longer allow me to select this option (it is grayed out on the
> dialog box). (see attached screenshot, if attachments work in this
> newsgroup)
>
> Examples of why this is valuable are editing local copies of web.config
> files without affecting the master, or prototyping a change on a file that
> someone else has checked out (we disallow multiple checkouts). In both of
> these cases, the two options provided by VSS 2005 are inappropriate.
>
> How can I return to the old behavior? Is there a setting that I missed
> that I need to change? (I looked pretty closely, but might have missed
> something)
>
> Thanks! --Erik Bailey
>
>
Thanks for your reply. I tested this, and the "Replace Writeable = Skip"
option does do what I want ... but that does it for ALL files in the batch,
not just the one specific one in question.
I understand all the caveats - please know that there are valid business
reasons to do this (another example - so we can have a master developer
web.config for our projects but each developer can make their own temporary
changes to their own computer, without doing a checkout of the master file
which would lock it from other edits). Like Dick Murillo in a parallel
posting in this thread, I've been using this functionality for years - it
makes no sense to remove it. When we use writeable files, we are extremely
careful to do a controlled diff on the latest version of the file before
checking in (besides, even if you make a mistake and forget, it's not like
the other user's changes are irretrievable - it's simply in the previous
revision, so this really isn't a major concern).
What I want to be able to do is exactly what I've done for many years - do a
Recursive Get Latest Version at the root ($/), or at any level, and be
prompted for EACH AND EVERY writeable file, and let me make the choice
individually. If I set the Advanced option as you (and Andrew McDonald in a
parallel post) describe, that sets it for ALL of the items dealt with in
that batch, giving me no opportunity to in fact replace just a single file
in the batch from VSS.
I have to wonder - are there any circumstances in which that option is NOT
grayed out? If not, why is it there on the dialog box at all? And what is
the point of the "Ask" setting for writeable files if it doesn't give me the
ability to do what I want (especially if there is an option you can set
explicitly that isn't allowed by "Ask")?
So here's where I'm ending up. I'm going to recommend the following behavior
to my team:
-- Tools / Options / Local Files / Replace Writeable Files = Skip. This sets
the option globally and prevents any inadvertant data loss, and ensures that
developers don't need to remember to go to the Advanced options *every
time*.
-- When a writeable local file needs to be replaced: hold down Shift and
right-click on the file to Get Latest version, click Advanced, change the
Replace Writeable setting to Replace, and click OK.
That seems excessively complicated. Is there any better way to do this?
--Erik Bailey
"Alin Constantin [MSFT]" <cn...@tfosorcim.moc> wrote in message
news:ODtYHHiB...@TK2MSFTNGP09.phx.gbl...
I and my team know that it is a bad idea... but we know what we are doing
and have been doing it successfully for almost 10 years (using VB 6).
To make it all much clearer... we have various EXE's with multiple DLL's
shared accross the EXE's
We have created VBG files that let us load EXE's with predefined sets of DLL
projects but not with all DLL's (too many DLL projects slows VB to a crawl
in our case)
When I start to work on a program I go and make a "Get Latest Version" on
the VSS Project. Before opening VB I do a "Get Latest Version" with the
"Make writable" option checked (if I don't, VB6 won't like that because of
the "read only" attribute on the VBG and VBP files).
Sometimes we have to add an additionnal DLL to the VBG file or make a change
on VBP files without checking them out (the nightly build must be able to do
a "Check Out" as it changes the version number inside them). During the
day, many CLS or FRM files can change and in case I need to get something
that someone else just changed I just go to the project and make a "Get
Latest Version" knowing that VSS will ask me the same question for 2 files
(the VBP and VBG file) to which I will answer "Leave the file". But with
VSS 2005... I can't do that anymore and I want to be able to... I know it's
dangerous... but as I said: "we know what we are doing" and also "we know
the risks".
Why does VSS gray out the "Leave this file" option when I specifically want
him to ask me....?
As Erik says: "What I want to be able to do is exactly what I've done for
many years - do a
Recursive Get Latest Version at the root ($/), or at any level, and be
prompted for EACH AND EVERY writeable file, and let me make the choice
individually."
And to quote him again: " I have to wonder - are there any circumstances in
which that option is NOT
grayed out? If not, why is it there on the dialog box at all? And what is
the point of the "Ask" setting for writeable files if it doesn't give me the
ability to do what I want (especially if there is an option you can set
explicitly that isn't allowed by "Ask")? "
I'd really like an answer on that last one ...
A long time Visual Source Safe user/supporter/evangelist,
Dick Murillo
"Alin Constantin [MSFT]" <cn...@tfosorcim.moc> a écrit dans le message de
news: ODtYHHiB...@TK2MSFTNGP09.phx.gbl...
> Why does VSS gray out the "Leave this file" option when I specifically
> want him to ask me....?
This is by design. The "Leave this file" option is unavailable if a checkout
local version can be done instead. Whether this was a good or bad design
decision, this is another story... We had no complains during the Beta
evaluation period about this change.
> I have to wonder - are there any circumstances in which that option is NOT
grayed out? If not, why is it there on the dialog box at all? And what is
the point of the "Ask" setting for writeable files if it doesn't give me the
ability to do what I want (especially if there is an option you can set
explicitly that isn't allowed by "Ask")?
Yes, during Get the Leave option is available if the local version of the
file cannot be determined for some reason (e.g. the user deleted by mistake
the vssver2.scc files), and checkout local version is not an available
choice. Also, the Leave option is available for other replace_writable cases
when a checkout choice doesn't make sense (e.g. during an UndoChekout). The
dialog is reused for all "replace writable" cases, and we thought it looked
funny with the empty space in the middle of the dialog if we'd hide the
option instead of disabling it.
The options is Ask because there are 2 choices on that dialog. If the
options are not what you expect them to be, that's unfortunate.
> another example - so we can have a master developer
web.config for our projects but each developer can make their own temporary
changes to their own computer, without doing a checkout of the master file
which would lock it from other edits
I know that disabling multiple checkouts is commonly used amongst VB
developers, and that it has been the default setting for VSS for so many
years, but VSS2005 is trying to change that.( e.g. on database creation
there is a second setting, copy-modify-merge model, that sets all the
settings to allow multiple checkouts, checkoout local version, etc, the same
way are set other source control systems).
For instance, a possible workaround in the above case is to enable multiple
checkouts on the database, and have each developer checkout the web.config
file if they need to change it locally. I see no good reason of using the
lock model - I still remmeber VB6 times when I had to ask and wait for
another dev to checkin his frm file so I can make a change to the same form,
and I hated that.
I can see though a problem of using multiple checkouts if the file that all
users wants to edit locally is a binary file (I don't remember what file
types are the vbg and vbp in Dick's example)
If the current behavior is a problem, I can only see the option of calling
product support and requesting a QFE for this issue.
--
Alin Constantin
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dick Murillo" <dmurill...@nospam.nospam> wrote in message
news:%23GF3Wem...@TK2MSFTNGP12.phx.gbl...
While I disagree (strongly) with the reasoning, I accept that this is a lost
cause for me.
I understand that there is a desire to shift people to the multiple checkout
model, but for our case (about 8 internal developers, mostly spread out on
different projects so there is rarely contention for files) we actively want
to stay on single-checkout because it assures that nothing inadvertant will
happen.
Was a detailed change description of VSS 6.0 vs. VSS 2005 published during
the beta period (e.g., was this change in methodology described anywhere)?
While I never actually installed the VS.NET 2005 beta, I would certainly
have reviewed a feature delta document with the same level of detail as I've
kept tabs on ASP.NET 2.0, C# 2.0, and Visual Studio 2005 (which was
considerable over the last 18 months). If such a detailed document was in
fact published, I'd love a pointer to it, since I've been essentially making
my own, based on research in this group and elsewhere on the web (and on
that topic, there's not a whole lot of info at www.microsoft.com/ssafe which
redirects you to a page mostly about v6).
So I'll be reviewing with the development team here about the pros and cons
of staying with the current single-checkout model (and having to deal with
writeable files using the convoluted mechanism I outlined in my earlier
post), versus moving to the multiple-checkout model.
Thanks for all the support you give (I want to especially thank you for your
website page on getting the HTTP model of VSS 2005 working - I could never
have done it without your detailed instructions).
--Erik Bailey
"Alin Constantin [MSFT]" <cn...@tfosorcim.moc> wrote in message
news:%23y$80S0BG...@TK2MSFTNGP09.phx.gbl...
> Was a detailed change description of VSS 6.0 vs. VSS 2005 published during
> the beta period (e.g., was this change in methodology described anywhere)?
The best document we had during beta was the VSS roadmap
http://msdn.microsoft.com//library/en-us/dnvsent/html/vssmap.asp
Unfortunately, the situation didn't got better even after VSS2005 shipped.
There is no good document describing new features in VSS2005, bug fixes or
changes, and that /previous/ssafe page is the homepage for VSS2005 :-(
It's up to the MSDN team now, and on our requests the feedback was they
didn't had much time lately. Oh well...
--
Alin Constantin
This posting is provided "AS IS" with no warranties, and confers no rights.
"Erik Bailey" <ebaileyREV...@org.ihi> wrote in message
news:e1E3gx0...@TK2MSFTNGP15.phx.gbl...
Here is another hack you may use:
- Make a backup copy of ssgui.dll (build 8.0.50727.42) from VSS folder
- Open VS2005
- File/Open/File, locate on disk ssgui.dll, click the dropdown on the Open
button, use OpenWith...Binary Editor
- Ctrl-F (File/Find&Replace/QuickFind), search for "53 8b c8 e8 4a f4 06
00" - there should be only one occurence, at 0006c3f2
- click in the text where the bytes are and replace them with "90 90 90 90
90 90 90 90"
- save ssgui.dll and close VS
With this change, the "Leave this file" option should be always available...
Alin
I must confess that I installed the beta version but did not try it on my
development PC.
Like Erik, I expected to see notes in the documentation or on the web about
this kind of change in design/behaviour. I agree that the multiple check
out scenario can be a good thing but I don't think it's a good reason to
change the behaviour of the single check out scenario.
VBG files are Visual Basic Group files that say what VBP's should be loaded
by VB 6.
Visual Source Safe has been very useful to us for many years, I hope the
MSDN team finds some time for you guys. You deserve to have something more
up to date on the MSDN site.
Your hack works pretty well so far. Thanks for the christmas gift!
A happy user!
Dick Murillo
"Alin Constantin [MSFT]" <cn...@tfosorcim.moc> a écrit dans le message de
news: %23qAtLv5...@TK2MSFTNGP12.phx.gbl...
Thanks for all your help on this issue - maybe a future update to VSS 2005
will restore this behavior (at least as an option)...
--Erik
"Alin Constantin [MSFT]" <cn...@tfosorcim.moc> wrote in message
news:%23qAtLv5...@TK2MSFTNGP12.phx.gbl...
Alin Constantin [MSFT] ha scritto:
One note: such hacks will also enable the "Leave" option for the
ReplaceWritable dialogs that might appear during Checkout (checkout does a
Get)
While I think that Leave option is safe to use during Get, the same option
used during Checkout will likely cause other team members to lose data (if
you checkin your file after that).
During Checkout, I strongly advise using Checkout Local Version option (the
one proposed by default by VSS)
--
Alin Constantin
This posting is provided "AS IS" with no warranties, and confers no rights.
"Luca" <lu...@nospam.it> wrote in message
news:eSjqzP4C...@tk2msftngp13.phx.gbl...
I agree that the same leave option used during Checkout
can cause data loss...
So I hope in the next sourcesafe service pack Microsoft
include this change only during the get request.
Luca
thank you so much for posting this workaround. It's not elegant but it does
exactly what I needed, and having just today upgraded to VSS2005 I'd already
be pulling out my hair about this otherwise.
I didn't have a chance to beta-test VS2005, if I had noticed this change I
would definitely have raised an objection. If you're considering feedback
for the future, I'd humbly suggest you might reconsider this use case. I
understand the rationale behind the change, but there are some times --
e.g., configuration files that need to be tweaked locally for each
machine -- when I have no intention of (or desire to) ever checking in the
changed version, and being forced to check it out to keep my local changes
is not at all what I want. I understand the risks of writable files, but
with care these can be safely managed.
Thanks again!
We are considering this change for a service pack. I think we can offer the
"skip" option when doing a Get, and disallow it only when doing a
"Checkout".
There are 2 bug reports on msdn product feedback site, plus these forums
posts, so I think there is a strong case for providing this functionality
back.
--
Alin Constantin
This posting is provided "AS IS" with no warranties, and confers no rights.
"I.R.F." <i...@newsgroups.nospam> wrote in message
news:%23e3G59i...@TK2MSFTNGP10.phx.gbl...
Thanks again for being so responsive!
"Alin Constantin [MSFT]" <cn...@tfosorcim.moc> wrote in message
news:OBwj10nQ...@tk2msftngp13.phx.gbl...