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