RE: GUI Diff on Repository HEAD and "a" directory?

I think I actually do understand the two systems.

The issue with VSS is that it's based on the "Check out and Lock" approach
to control in which it's default configuration is such that at any given
time it is assume that only one person has a particular file "checked out
for modification" and until that one person checks their stuff back in, no
one else is really suppose to be making any modifications to any copy of
that same file. So, in VSS, multiple developers really can't (or rather are
not expected to) check out files to their own working directories and work
on them simultaneously and then "check them in when they are finished". The
default work flow for VSS is, developers that need to work on a particular
file are basically suppose to "queue up" for access to the file and each
person takes their turn at changes one at a time.

This is evident to some extend by the fact that VSS comes with a Diff tool
that can show difference between a maximum of two sources (which actually
default to diff-ing the current "HEAD" to the file in the working folder)
and it has absolutely no support for any kind of Merge functionality.

Though that's the default and assumed work flow in VSS, that's not the way
we tend to use it so we have had to "work around" this situation. In VSS
you are not allowed to "check out" a file if someone else already has it
checked out, so the alternative is for the "second guy" to do a "get latest
copy" to retrieve a set of code he can work on in his "working folder".
Then, when you finishes, if/when the "other guy" (the one who actually
formally checked it out) has checked the same file back in, the "second guy"
can perform a "Check Out without getting local copy" function. This causes
the VSS server to flag the files as having been checked out by the second
guy (so he can subsequently check them back in) without overwriting the
changes he made while waiting for access. Then, that second guy performs a
Diff between his working directory and the repository files (which now
contains the changes made by the first guy).... performs manual merges if
necessary in his working directory to "merge" guy one and guys two's changes
then he checks his code back in.

I complete recognize that this approach is NOT the same that SVN takes which
does allow any and all to check out anything whenever and then check back in
when they feel like it too.

I'm pretty sure I'm right about this partly because when I was first
starting to compare VSS and SVN and CSV many of the articles I read,
specifically discussed the fundamental difference in the approaches of the
product with respect to "to Lock or Not to Lock... that is the question".

In VSS, all the REALLY control happens at the repository database not in the
working folder. You can delete the goofy files that VSS creates in your
working folder when you check code out with pretty much no ill effects. My
current understanding of SVN is that if I were to do the functional
equivalent in SVN (delete the .svn directory in my working folder) I'd
pretty much shooting myself in the foot from a version control perspective.
This, to me, pretty clearly demonstrates one of the fundamental differences
in the products, SVN is very "Client focused" ("it's all about the working
directory and the .svn data") VSS is very "Server focused". Further, VSS
can take the "server focus" approach because it ASSUMES that at any given
time one and only one person will be actively modifying a file and really
it's only job is to 1) tell other people to pound sand if they want to try
to work on the file and 2) keep a running log of changes to the file as it's
checked in.

-----Original Message-----
From: Oefelein, Martina [mailto:Martina.Oefelein@dionex.com]
Sent: Wednesday, March 21, 2007 1:27 PM
To: Tom Malia; users@subversion.tigris.org
Subject: RE: GUI Diff on Repository HEAD and "a" directory?

Hi Tom,

I think you have a fundamental misunderstanding of how bot VSS and SVN work.

Both systems have a concept of a "working copy" (SVN) or "working folder"
(VSS) where developers do their development. Each developer has her own
working copy, where they can work independently from each other and commit
their changes back to the repository when they have finished a piec of work.

While both systems support a way of exporting a copy of the repository to a
non-working directory, this is not intended to perform any changes in such
exports. Exports are intended for deployment, source distributions, or build
machines, but doing changes in an export is just WRONG for both systems.

ciao
Martina

-----Original Message-----
From: Tom Malia [mailto:tommalia@ttdsinc.com]
Sent: Monday, March 19, 2007 7:18 PM
To: users@subversion.tigris.org
Subject: RE: GUI Diff on Repository HEAD and "a" directory?

>> Maybe I'm missing some of the intrinsic details of the product you are
>> working on. Having one developer checking out the entire project and
>> by doing that locking everyone else out doesn't seem (to me)
>> appropriate _even_with_VSS_. No offense, but the fact that most of the
>> time everyone on the team minus one lucky guy has to work on unmanaged
>> files doesn't really sound very functional.

Actually, as I've mentioned in a prior post, some of this confusion I think
is stemming from a fundamental difference in how VSS and SVN "manage" code.
In the Case of VSS, the code in a working directory is not really "Managed"
in any real sense. Checking code out of VSS, from the perspective of the
working directory, is much the same as performing an Export from SVN.

In the scenario I described in VSS where one guy Checks out the code, and
the rest work on an "unmanaged" copy, the only real difference between the
guy that actually checked it and the rest is back on the VSS SERVER the
project is marked as having been checked out by the one guy and no one else
will actually be allowed to check their changes in until he first checks his
changes in. That's the only real difference.

So far, from my developing understanding of SVN, I think an analogous
scenario in SVN would be something like:

1) Programmer 1 (the "lucky guy") checks out the entire project and starts
developing in the same working directory he checked out to. This "lucky"
guy can perform standard "diffs" against his base when we wants to see
exactly what he has changed.
2) The others (the "unlucky guys") check out the entire code to a SVN
working directory, then they export the exact same code to another
directory. These guys do their development in the exported code and perform
Diff's against the "real" svn working directory when they want to see what
changes they've made since they checked things out.

By the way, I've played around with a few 3rd party client utilities for
Visual Source Safe that attempt to overcome the performance problems
inherent in WAN access to VSS... I now realize that what those tools do is
basically the scenario I just described for how you would duplicate my
environment SVN.

Regards,
Tom Malia

p.s. if at any point you think I'm wasting the forums time with this
discussion, just tell me to shut up... I'm actually continuing to ramble
mostly because I hope that by discussing my evolving understanding of SVN in
the context of my existing understanding of VSS mat help others that might
try to make the same transition later.

-----Original Message-----
From: Jing Xue [mailto:jingxue@digizenstudio.com]
Sent: Monday, March 19, 2007 12:41 PM
To: users@subversion.tigris.org
Subject: RE: GUI Diff on Repository HEAD and "a" directory?

Quoting Tom Malia <tommalia@ttdsinc.com>:

> [Tom Malia] It's a team development is the issue. at any given time, I've
> got 2 or three programmers (non-in the same geographic area) working on
the
> code for a single EXE. Some working on some features and bugs and others
> working on other features and bugs. In VSS, you don't have "merge"
> functionality so frequently one person checks the project out while other
> "get latest version" (the equivalent of export) and every works on the
stuff
> they need to work in. Then, before you "check in" if you were one of the
> ones that just did an export, you Diff the entire project in your working
> folder against the current contents of the repo version of the project
then
> go through and manually perform a merge and then check your stuff into the
> repo. I know this isn't the way things are "suppose to be done" but it's
> how things are done and it's really fairly functional for us for right
now.

Maybe I'm missing some of the intrinsic details of the product you are
working on. Having one developer checking out the entire project and
by doing that locking everyone else out doesn't seem (to me)
appropriate _even_with_VSS_. No offense, but the fact that most of the
time everyone on the team minus one lucky guy has to work on unmanaged
files doesn't really sound very functional.

-- 
Jing Xue
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org