Yeah I know thats a strange topic. Basically I am a big fan of
subversion, I converted from CVS a several of years ago when I finally
got frustrated with some of CVS's deficiencies. I then went back to CVS
briefly because that was what my department was using, I had finally
begun to persuade them to move over to subversion when I decided it was
time for me to leave and get a new job.

I have now moved jobs and my present employers are using VSS, as much
as I would love to just say to them "VSS is shite and dangerous and you
should stop using it now!" this is a little hard given that I have only
been with them a couple of months and am also about the most junior
person here.

So in the meantime, while I begin my slow approach to educate them as
to what "revision control" really means, I am stuck with using VSS. Or
at least so they think! Currently I maintain a local/personal
subversion repository (nicely backed up on my network share), I do all
my work in this and get to use my tried and tested development model.
To get around the problem with VSS, I have a seperate "vss" branch
which I used to move changes to and from my development trunk.

My approach is typically something like this:

1. Make changes in trunk (or in branch if I feel its a significant
change etc...) just like I normally would if I were using SVN on its
own.

2. Once I feel changes are working in trunk, I load up VSS and make
sure my working copy of "vss" is up to date with the VSS repository.

3. I merge differences between "vss" and "trunk" into "vss", thus
bringing "vss" up to speed with "trunk".

3. I check out changed files (yes this is a bit dangerous not checking
them out before I do the merge, but I get away with it because we are
using a remote repos for which we only have one client license).

4. I commit changes to VSS, recheck out latest (to get comments and VSS
changes to auto headers etc...).

5. I commit changes into "vss" branch

6. I merge changes between "vss" HEAD and previous commit to trunk, to
get the changes to the headers etc...

7. I commit changes to trunk, and voila "trunk" and "vss" are
identical.

However some have you may already have spotted the problem here. When I
repeat this ALL files that were changed in/by VSS, and thus needed to
be recommitted to "trunk" in stage 7, result in higher revision numbers
in "trunk" than "vss". This means that the next time I perform the
merge from "trunk" into "vss" I end up with files listed in the merge
dialog which have obviously not been changed. This is quite an
annoyance because with my awful memory I cannot always remember which
files exactly have been changed and to verify which files have changed
before committing to VSS I need to delve into the directories and
inspect them. Its not the end of the world, but it would be nice if the
merge dialog gave an accurate reflection of which files really had
changed.

Now to the point (sorry about the ramble), does anyone have a better
suggestion on how I might achieve the same results?

Ta

Adam

Adam,

I noticed you weren't getting an overwhelming response to your question
and thought I would chime in with the obvious question - why are you
doing this in the background?

If the process is going to fail (and in most cases VSS will...) the
best way to esnure change might just be to LET it fail. Document the
shortcomings of VSS: size limitations, exponential growth with version
labels, etc. As you encounter these failure points (and we all know
that you WILL encounter them), you can make a case for the tool of your
choice.

Just one more opinion here and then I'll go away If you succeed in
migrating their version control to a better tool, go for the gusto.
Settle for Subverion and be happy if that's the end result, but shoot
for a true Configuration Management tool. If there's going to be a
change - get the most out of it that you possibly can. There are
several good, inexpensive tools that are supported and stable: AccuRev
is my personal favorite.

By pushing for a CM tool, rather than just another version control
tool, you'll have more selling points to support a change in tools, as
well as a more solid process in the long run.

Here's wishing you the best


Fran Schmidt
Configuration Manager
Source Medical Inc.
Birmingham, AL:


subs@adamsutton.co.uk wrote:

Ta for the response Fran,

I am certainly reading a lot about the problem with VSS, but there are
several problems which make it difficult for me to begin suggesting
sweeping changes within the company. As a explained in my previous
post, I have only just joined the company and I am very junior. The
company has been using VSS for several years and I have not heard
anybody complain about major problems, though I know there are
certainly people who I have heard grumble a little (but having only
just started here its difficult to truely guage peoples opinions).

Also a lot of people don't really seem to use VSS properly, quite
probably because its so lacking in features they resort to other
haphazard personal techniques and then use VSS just for code sharing
and keeping a basic history of our source code. Though this might only
be indicative of the small project I am working on and not others,
again I have not yet been here long enough to guage things properly.

I am certainly making a note of the deficiencies in VSS, which from my
point of view are huge, I really can't see how anybody makes it work as
a revision control system.

As for a full blown change/configuration management system, I'm not a
huge fan of integrated solutions, I often find them restrictive. I
prefer to stick to the UNIX philsophy of using lots of smalls tools
held together with a bit of glue. I find that way you get the tools you
find most suitable for each aspect of the task.

That said I cannot really comment on many change/config management /
revision control tools, since I do not have all that much experience,
and its not really something I am into spending too much time
investigating. Personally once I find a tool (or set of) that I am
happy with then I tend to stick with them. Also a lot of the other
config/change management features we would use are currently management
by in house tools, again I have yet to really come into contact with
them (I think its an unfortunate consequence of the project I am on)
and so cannot comment on their merits. However its difficult to come
into a company and after a couple of months say "hey that tool your
using is crap" but its a whole other story trying to tell them this
when they have personally developed the tool in question.

All that said, thanks for the response and the support.

Adam

Alrighty - I'm not sure how much this will help, but I'll give you what
I can...
What you need is a way to auto-diff the files to determine what has
actually changed...well, that's one thing anyway. Maybe an auto-merge
would be helpful as well.

If there is a way to do a text level diff, it would probably be
completely impractical due to the time it would take. However, by
applying labels, you might be able to get the same result.

The basic theory is this:
1) Apply a build label to all the elements in the initial branch
2) Edit the script below to GET by label for the previous build
3) Edit the script below to DIFF based on new label vs previous label
4) Pipe the results into a text file

Here's the part you'd need to write from scratch:
Write a quick "for i in diff.txt" script that will run the vss merge
via command line. This will take you through every single item that
has actually changed.

I'm pasting a portion of our old build scripts below, in the hopes that
you can edit it to suit your needs. I've removed everything
proprietary. This is the portion of the script that applies the
labels, does the get and then the diff.

Last comment from me: Not all integrated systems are like Rational. If
you've had a bad expereince with Rational, please don't let that stop
you from looking at the truely good, powerful and FLEXIBLE integrated
tools that are out there

Here's portions of two scripts:

@echo off

if /i "%VSSLABEL%"=="TIP" goto END

Rem Line below will call build.cmd first and then call this file to
make sure the environment is set
If "%BuildDrive%" =="" goto Recall

SETLOCAL

Rem Take away 1 from current build number (VSSLABEL) if the LastBuild
isn't defined
IF "%LASTBUILD%"=="" SET /A LastBuild=VSSLABEL-1
SET VSSReportf=%DestPath%\VSS_Changes_%LastBuild%_to_% VSSLABEL%.wri
SET
VSSReportb=%DestPath%\VSS_Changes_%LastBuild%_to_% VSSLABEL%_Summary.wri
SET
VSSReportfS=%DestPath%\VSS_Source_Changes_%LastBui ld%_to_%VSSLABEL%.wri
SET
VSSReportbS=%DestPath%\VSS_Source_Changes_%LastBui ld%_to_%VSSLABEL%_Summary.wri

@echo VSS Report - Build %VSSLABEL% to %LastBuild% full
@echo.
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo VSS Report - Build %VSSLABEL% to %LastBuild% full >>"%OUTLOG%"
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo.

%SSDIR%\WIN32\SS History "%VSSProj%" -O"%VSSReportf%"
-VL"%BTYPE%_%VSSLABEL%"~"L%BTYPE%_%LastBuild%" -R
%SSDIR%\WIN32\SS History "%VSSProj%/Source" -O"%VSSReportfS%"
-VL"%BTYPE%_%VSSLABEL%"~"L%BTYPE%_%LastBuild%" -R

@echo VSS Report - Build %VSSLABEL% to %LastBuild% brief
@echo.
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo VSS Report - Build %VSSLABEL% to %LastBuild% brief
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo.

%SSDIR%\WIN32\SS History "%VSSProj%" -O"%VSSReportb%"
-VL"%BTYPE%_%VSSLABEL%"~"L%BTYPE%_%LastBuild%" -B -R
%SSDIR%\WIN32\SS History "%VSSProj%/Source" -O"%VSSReportbS%"
-VL"%BTYPE%_%VSSLABEL%"~"L%BTYPE%_%LastBuild%" -B -R

@echo VSS Report - End
@echo.
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo VSS Report - End >>"%OUTLOG%"
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo.
CD /d "%BasePath%"
EndLocal
goto End

:Recall
Rem Call the build.cmd file to setup environment and recall this
script.
Call Build %0 Recall

:END


And the next script:

@echo off

Rem Line below will call build.cmd first and then call this file to
make sure the environment is set
If "%BuildDrive%" =="" goto Recall

@echo BUILD - Label Source Code in VSS (%VSSLabel%) if required
@echo.
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo BUILD - Label Source Code in VSS (%VSSLabel%) if required
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo.
Rem Only Label when user is SSUser is set to Build, VssLabel isn't
"TIP" and SSRelabel is set to Y.
if /i "%SSUSER%"=="build" if /i not "%VSSLabel%"=="TIP" if /i
"%SSRelabel%"=="Y" %SSDIR%\WIN32\SS Label "%VSSProj%"
-L"%BTYPE%_%VSSLabel%" %VSSReply% -C"Built %VSSLabel% on
%COMPUTERNAME%" "-O&%OUTLOG%"
if /i "%SSUSER%"=="build" if /i not "%VSSLabel%"=="TIP" if /i
"%SSRelabel%"=="Y" %SSDIR%\WIN32\SS Label "$/Utilities"
-L"%BTYPE%_%VSSLabel%" %VSSReply% -C"Built %VSSLabel% on
%COMPUTERNAME%" "-O&%OUTLOG%"

@echo BUILD - Get Source Code with %VSSLabel% Label
@echo.
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo BUILD - Get Source Code with %VSSLabel% Label
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo.
Rem Get Source with or without label when SSReget is Y
if /i "%VSSLabel%"=="TIP" if /i "%SSReget%"=="Y" %SSDIR%\WIN32\SS
GET "%VSSPROJ%/Source" -R -GTM -GL"%BasePath%\Source" -I-N
"-O&%OUTLOG%"
if /i Not "%VSSLabel%"=="TIP" if /i "%SSReget%"=="Y" %SSDIR%\WIN32\SS
GET "%VSSPROJ%/Source" -R -VL"%BTYPE%_%VSSLabel%" -GTM
-GL"%BasePath%\Source" -I-N "-O&%OUTLOG%"

@echo BUILD - End
@echo.
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo BUILD - End >>"%OUTLOG%"
@echo
------------------------------------------------------->>"%OUTLOG%"
@echo.
goto End

:Recall
Rem Call the build.cmd file to setup environment and recall this
script.
Call Build %0 Recall

:End



subs@adamsutton.co.uk wrote:

Thanks again for the response Fran, however it does seem overly
complicated for what I am trying to achieve. I think I will stick with
my current approach for now, I was really looking for an approach that
required as little VSS use as possible as I find it such an awful tool.

I decided that the best approach was rather than to merge into my "vss"
branch, differences between current state of that branch and my "trunk"
branch I would simply make a more obvious log message at the point
where I merge VSS changes into "trunk". That way I can easily spot this
log message and perform the merge between this revision number and
HEAD. Thus removing the redundant update output during the merge.

I haven't really used Rational tools, we considered them a few years
ago for a project at my previous job. However we came to the conclusion
that for the scale of the project we were working on the cost couldn't
be justified and the complexity was not required, so settle for an
adhoc set of tools which each best matched our needs (both cost and
features) in the relevant area.

I have not really experienced that many commercial tools yet, since my
previous job was working at a research institute where software quality
was kinda secondary to demonstrating scientific feasability and so
expensive tools were deemed unnecessary. So for now I only have
experience with free tools, some of which I find are extremely good,
more than adequate for my needs. However most attempts to provide fully
integrated environments including such features as revision control,
design tools, bug tracking and document management (these are the ones
I am most likely to use) always fall slightly behind in each area
compared to the best tool focused at that particular area. I don't know
whether this is the case with commercial tools, though given the cost
of some of them, I would sincerely hope not.

Thanks for the help and advice,

Adam

"subs@adamsutton.co.uk" <subs@adamsutton.co.uk> wrote in
news:1152259253.178017.184100@s16g2000cws.googlegr oups.com:


Another issue to consider is proprietary data formats with no means to get
the data out when you decide to switch horses. For example, VSS data that
you want to convert to some other revision control system.

Subversion does provide the benefit of an open format and a standard API
that integrators can use. This results in 3rd party support like Tortoise
for Windows Explorer integration, Ankh for Visual Studio integration, and
Trac for website wiki and issue tracking.

When considering a commercial closed-format solution, ask your vendor what
you need to do the day they close their doors or decide to move on to
another product and EOL the one they sold you.