![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
| Welcome to Windows Vista Forums. Our forum is dedicated to helping you find solutions with any problems, errors or issues you are experiencing with Windows Vista. The Vista forum also covers news and updates and has an extensive Windows Vista tutorial section that covers a wide range of tips and tricks. |
| |||||||
![]() |
| |
| | #1 (permalink) |
| | Dealing with the conflict between $Revision and AllSigned Here is the problem. We have AllSigned on on all systems therefore scripts must be signed even to be tested. When ready for QA they are submitted to SourceSafe. QA extracts from SourceSafe to test and if approved PC installs from SourceSafe. Neither QA or PC can sign a script and developers can't install to QA or production. Historically we've used the $Revision keyword to maintain version numbers. For example in SSRS we use a formula like this to display the version: =Replace(Replace("$Revision: 2 $","$Revi","Report Format Ver"),"$","") These practices seems to butt heads because the $Revision keyword replacement occurs on submission rather than checkout and thus submission invalidates the signature. Does anyone have a method to insure the version reported by a script matches the sourcesafe version while retaining the requirement that submitted source be properly signed? |
My System Specs![]() |
| | #2 (permalink) |
| | Re: Dealing with the conflict between $Revision and AllSigned On Apr 16, 6:37*am, RickB <rbiel...@xxxxxx> wrote: Quote: > Here is the problem. > > We have AllSigned on on all systems therefore scripts must be signed > even to be tested. > When ready for QA they are submitted to SourceSafe. > QA extracts from SourceSafe to test and if approved PC installs from > SourceSafe. > Neither QA or PC can sign a script and developers can't install to QA > or production. > > Historically we've used the $Revision keyword to maintain version > numbers. > For example in SSRS we use a formula like this to display the version: > =Replace(Replace("$Revision: 2 $","$Revi","Report Format Ver"),"$","") > > These practices seems to butt heads because the $Revision keyword > replacement occurs on submission rather than checkout and thus > submission invalidates the signature. > > Does anyone have a method to insure the version reported by a script > matches the sourcesafe version while retaining the requirement that > submitted source be properly signed? ![]() More seriously, either stop using expansion variables and let the VCS keep track of what version you have (which is one of its jobs). OR stop deploying directly from VSS. OR do not deploy from the same location in VSS where you develop. Have a separate location where you check in without expanding variables. |
My System Specs![]() |
| | #3 (permalink) |
| | Re: Dealing with the conflict between $Revision and AllSigned On Apr 20, 3:43*pm, jasonmarc...@xxxxxx wrote: Quote: > On Apr 16, 6:37*am, RickB <rbiel...@xxxxxx> wrote: > > > > > Quote: > > Here is the problem. Quote: > > We have AllSigned on on all systems therefore scripts must be signed > > even to be tested. > > When ready for QA they are submitted to SourceSafe. > > QA extracts from SourceSafe to test and if approved PC installs from > > SourceSafe. > > Neither QA or PC can sign a script and developers can't install to QA > > or production. Quote: > > Historically we've used the $Revision keyword to maintain version > > numbers. > > For example in SSRS we use a formula like this to display the version: > > =Replace(Replace("$Revision: 2 $","$Revi","Report Format Ver"),"$","") Quote: > > These practices seems to butt heads because the $Revision keyword > > replacement occurs on submission rather than checkout and thus > > submission invalidates the signature. Quote: > > Does anyone have a method to insure the version reported by a script > > matches the sourcesafe version while retaining the requirement that > > submitted source be properly signed? > Stop using VSS? * ![]() Quote: > More seriously, either stop using expansion variables and let the VCS > keep track of what version you have (which is one of its jobs). * the version of a file? Does it have some kind of IDENT command? Even if this were true I don't see it being useful in cases where a script user needs to report which version of a script they have. Quote: > stop deploying directly from VSS. *OR do not deploy from the same > location in VSS where you develop. *Have a separate location where you > check in without expanding variables. be wrong or we need to maintain the version number manually in which case deploying from VSS is no longer a problem. As I said, I'm trying to find a way to maintain both the version number and the script's signature. Best I can tell, that seems to mean I need to somehow predict the version number with guaranteed accuracy and insert it before signing the script. I really can't think of any way to do this regardless of the VCS other than to write a script that is somehow required to be used to submit changes and I don't see a way to require the use of a script. Even if the requirement can't be enforced, such a script does not seem to be a simple thing to write. |
My System Specs![]() |
![]() |
| Thread Tools | |
| |
Similar Threads | ||||
| Thread | Forum | |||
| motherboard revision | General Discussion | |||
| Vista Security Update Revision | Vista News | |||
| DLink DWL-G510 Revision B PCI Network Adapter Driver | Vista networking & sharing | |||
| Checking revision of nVIDIA display device driver | Vista General | |||
| Dealing with UAP within the command prompt | Vista account administration | |||