Developer Forum

Hi,
I have a typical problem where I am having n number of VSS
Database at some location where different development
teams work on & at the end of day I want to replicate the
changed part of each VSS database to some other physical
location.
Now the problem is I cannot take backup & restore of each
database each day & then restore it at other location.Wat
can be the possible methods & ways by which i can
replicate or sync VSS DB with minimal amount of file size
transfered across network.

Build a batch job to robocopy the database. Robocopy will
only copy files that are changed.

VSS
the
each
location.Wat
size

Hi Rich,
Well in my current scenario i have n VSS databases at one
physical location & i replicate the same VSS database at
some other physical location & area.
Now Since development team works on 1 physical location &
Management Team works on other.At the end of each day I
want to sync everything.
Now my problem is if i make a small change in a file
amounting to 1 MB then replication can be 40MB also
depending on the files it had internally affected.

Is there any way out by which I can do replication of my
VSS daily. I heard there is some way out using SQL Server
but I am not sure.
Looking forward for some +ve response.

Himanshu
ONE other
databases into one
fact you may end
you're just doing
that you have
the destination.
progress, only part of
database replication.
posts.
confers no rights.
Location
microsoft.public.vstudio.sourcesafe:5037
will
physical

Hello Rich Knox,

I'v read your answer about "Replicating VSS DB Changes
Daily to Other
Location" (Aug 27 2003) from Himanshu Bhargava.
see also : http://www.yqcomputer.com/
My problem is similar.
I have two databases (db1 and db2). Database db1 is on the
machine M1 =
at
city1 and db2 is on the machine M2 at city2; but the two
machines are =
not
connected.
Development teams work on db1 and they work at db2.
The development teams must to replicate the changed part
of the two VSS
database to other physical location.
My goal is, to keep the latest file in both directory
trees!
Your piece of advice:
"... On the other hand if you're just doing a ONE to ONE
copy, then =
Robocopy
can help, but I'd advise that you have everyone log out of
the source
database before copying to the destination... "
I'v read the discription of ROBOCOPY and I found the
option /XO =
(Excludes
Older files).
I'v thougth: The developer stores db1 to data medium
("tdb"), takes the =
data
medium "tdb" to the other city2 and copies with the
following copy =
option
/XO:
"ROBOCOPY %source% %destination% *.* /E /XO"
(source=3D"tdb", =
destination
=3Ddb2)
After finishing development he stores db2 to data medium
("tdb"), takes =
the
data medium to city1 and copies with option /XO =20
"ROBOCOPY %source% %destination% *.* /E /XO"
(source=3D"tdb", =
destination
=3Ddb1)

But I see some problems!:
I'v some Problems with connected folder/files, when I
replicate the two
databases!

I hope, you can understand my question and my way of
soloution.
Can you help me ???


Mit freundlichen Gr=FCssen / best regards=20
Annelie Rehnert

i Anne,
Sorry to take so long getting back to this thread. You pose a somewhat
complicated problem that SourceSafe really wasn't designed to handle. That
is synchronizing two databases. I don't think robocopy is appropriate here
because you have developers making independent changes to both databases.
My answer was premised on the idea of updating a destination database from
changes in a source database. My assumption was that the changes always
flowed in one direction, db1 to db2. In your case changes flow in both
directions.

How isolated are the areas that the two development groups work in. Suppose
for example the developers in City1 all work on files located in a sub-tree
under $/DevGroup1. The City2 developers work on code under $/DevGroup2. But
suppose also these two projects had dependencies. Maybe DevGroup2 relies on
libraries built from the code in DevGroup1. If this were the case, you
might periodically do the following:
* Get latest on the $/DevGroup1 sub-tree.
* Copy the files to some storage medium.
* Go to City2.
* Check out everything in the $/DevGroup1 sub-tree.
* Copy the files from the storage medium.
* Check everything back in.
This would bring the developers in City2 up to date on the work done in
City1. You'd have to do some special handling for adds and deletes. You
might use SourceSafe's journal mechanism to track this or you could write
code to use the SourceSafe command line or OLE automation interfaces to
step through the recent history of the project and identify the adds and
deletes. You could also use this to do a get latest on just the files that
had changed to reduce the demands on the storage medium.

On the other hand if both development groups are modifying files in the
same tree or worse yet modifying the same files, you have a much more
difficult problem. You may need to merge changes to the same file. I could
imagine a mechanism to compare change histories on the two databases and do
the right thing to merge them, but writing the code to do this reliably
would be a difficult and expensive undertaking.

I'm sorry I can't be more encouraging, but replication is really beyond the
capabilities of the current version of SourceSafe.

- Rich Knox [MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
| From: "Anne" < XXXX@XXXXX.COM >
| Subject: RE: Replicating VSS DB Changes Daily to Other Location
| Date: Thu, 4 Sep 2003 02:42:02 -0700
|
| Hello Rich Knox,
|
| I'v read your answer about "Replicating VSS DB Changes
| Daily to Other
| Location" (Aug 27 2003) from Himanshu Bhargava.
| see also :http://msdn.microsoft.com/newsgroups/default.asp
| My problem is similar.
| I have two databases (db1 and db2). Database db1 is on the
| machine M1 =
| at
| city1 and db2 is on the machine M2 at city2; but the two
| machines are =
| not
| connected.
| Development teams work on db1 and they work at db2.
| The development teams must to replicate the changed part
| of the two VSS
| database to other physical location.
| My goal is, to keep the latest file in both directory
| trees!
| Your piece of advice:
| "... On the other hand if you're just doing a ONE to ONE
| copy, then =
| Robocopy
| can help, but I'd advise that you have everyone log out of
| the source
| database before copying to the destination... "
| I'v read the discription of

i Rick,
thank you for the Massage.
I have the problem, that both development groups are
modifying files in the
same tree or worse yet modifying the same files.
I think there must be other users with the same problems.
I don't know, if there a good solution ; to use internet ?
Sorry, I had have hollidays. Because that I read your
answer in the morning.

Annelie
pose a somewhat
designed to handle. That
appropriate here
both databases.
destination database from
changes always
flow in both
groups work in. Suppose
located in a sub-tree
under $/DevGroup2. But
DevGroup2 relies on
the case, you
the work done in
and deletes. You
you could write
interfaces to
identify the adds and
just the files that
modifying files in the
a much more
same file. I could
two databases and do
this reliably
really beyond the
confers no rights.
Location
also :http://msdn.microsoft.com/newsgroups/default.asp
the
two
part
ONE
of
medium

ccessing VSS over the internet may be the best solution. There are some
caveats to consider, though:

* VSS performance is slow over low bandwidth, high latency connections.
Performance may be adequate at DSL speeds, but it's painfully slow on 56K
modems.
* VSS database corruption can occur if the network connection is lost
during a check in.

We're currently working to improve SourceSafe's performance and reliability
over slow and sometime intermittent connections. Future versions should
have a better story for this situation. In the meantime you might look at
products like Source Offsite (http://www.sourcegear.com/sos/index.asp),
which address the problem of accessing SourceSafe databases over the
internet.


- Rich Knox [MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
| From: "Annelie Rehnert" < XXXX@XXXXX.COM >
| Subject: RE: Replicating VSS DB Changes Daily to Other Location
| Date: Mon, 29 Sep 2003 04:02:48 -0700
|
| Hi Rick,
| thank you for the Massage.
| I have the problem, that both development groups are
| modifying files in the
| same tree or worse yet modifying the same files.
| I think there must be other users with the same problems.
| I don't know, if there a good solution ; to use internet ?
| Sorry, I had have hollidays. Because that I read your
| answer in the morning.
|
| Annelie
| >-----Original Message-----
| >Hi Anne,
| >Sorry to take so long getting back to this thread. You
| pose a somewhat
| >complicated problem that SourceSafe really wasn't
| designed to handle. That
| >is synchronizing two databases. I don't think robocopy is
| appropriate here
| >because you have developers making independent changes to
| both databases.
| >My answer was premised on the idea of updating a
| destination database from
| >changes in a source database. My assumption was that the
| changes always
| >flowed in one direction, db1 to db2. In your case changes
| flow in both
| >directions.
| >
| >How isolated are the areas that the two development
| groups work in. Suppose
| >for example the developers in City1 all work on files
| located in a sub-tree
| >under $/DevGroup1. The City2 developers work on code
| under $/DevGroup2. But
| >suppose also these two projects had dependencies. Maybe
| DevGroup2 relies on
| >libraries built from the code in DevGroup1. If this were
| the case, you
| >might periodically do the following:
| > * Get latest on the $/DevGroup1 sub-tree.
| > * Copy the files to some storage medium.
| > * Go to City2.
| > * Check out everything in the $/DevGroup1 sub-tree.
| > * Copy the files from the storage medium.
| > * Check everything back in.
| >This would bring the developers in City2 up to date on
| the work done in
| >City1. You'd have to do some special handling for adds
| and deletes. You
| >might use SourceSafe's journal mechanism to track this or
| you could write
| >code to use the SourceSafe command line or OLE automation
| interfaces to
| >step through the recent history of the project and
| identify the adds and
| >deletes. You could also use this to do a get latest on
| just the files that
| >had changed to reduce the demands on the storage medium.
| >
| >On the other hand if both development gr