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

I don't really want to keep the two systems going long term.

Basically, a lot of my parallel issues are the result of my attempt to do
what you are describing as some "trial runs". My hope was that I could
basically do the trial runs behind the scenes using the activity that is
still going on for my developers as they continue to work with VSS. Once I
feel I've got the issues and kinks worked out, I wanted to try to ease my
developers into the environment as well.

However, the issue of wanting to be able to Diff, arbitrary directories in
the real file system against things in the SVN repository, I suspect will be
a continuing issue even after I do a complete switch to SVN. The nature of
the development community I'm working in is such that project source code
does fairly regularly get passed from organization to organization for a
variety of different reasons. Most of the other organizations that I might
need to pass code to and from are not familiar with version control at all,
a few use VSS and many of the developers in this community, just to give you
an idea of what I'm dealing with here probably don't even now how to open
the command prompt window anymore.

Now, that all said, the other realization I'm beginning to get my head
around is, one of the key architectural differences between VSS and SVN is,
VSS is basically all "Server based" and SVN is basically all "Client based".
By this I mean, all of the information about what's currently checked out
and what's current changed, and where the working copies are and everything
in Visual Source Safe is actually stored on the server where the repository
database is located. Next to nothing is actually stored in the client side
working directory. There are a couple of files that VSS writes to the
working directory when you check things out, but the fact is you can pretty
much delete those at will and still be able to perform any and all of the
version control functions you might want to perform. Where as with SVN,
it's pretty much all about the contents of the ".svn" folders in your
working directory. they seem to be key to the whole thing.

I could well be way off base in this interpretation and I'm certainly open
to clarification from others.

It's certainly not that I think one approach is right or wrong either. I'm
finding serious advantages and disadvantages with both approaches.. The
"server based" solutions of VSS for example basically give you complete
freedom to do what ever the heck you feel like doing anywhere you want to
for your actual development. then when you actually want to do any version
control stuff, you just match the right entity in the repository (file or
folder) with the right entity in the file system (file or folder) and doing
your thing (i.e. Diff, check-in, revert, copy over , etc. etc.) . This has
some real advantages..It also has some real disadvantages.. For example,
you're ALWAYS going back to the repository for any version control
functionality which means you can't do any of these functions if you can't
get access back to the repository (ergo, no disconnected version control
functionality) and if the repository is across a WAN everything can be quite
slow. Also, in the VSS structure, the software itself can't do nearly as
much in the way of keeping track of changes across branches in the code and
things.

As you all have been telling me, it's a different world. I can accept that
that is the fact, but I'm the type that needs to work through those
differences in detail and I need to understand where, when and WHY the
particular difference exist.

Regards,
Tom Malia

  _____

From: Oefelein, Martina [mailto:Martina.Oefelein@dionex.com]
Sent: Monday, March 19, 2007 11:26 AM
To: Tom Malia
Cc: Subversion Users mailing list
Subject: RE: GUI Diff on Repository HEAD and "a" directory?

Hi Tom,

so you are trying to track the same changes in two version control systems
at the same time?

I wouldn't do this. Instead, set a fixed tate and time where the developers
have to check in everything e.g., then lock the VSS repository so that
nobody can commit anymore. Migrate the repository to SVN, then have the
developers check out a new working copy from SVN.

Even with a fairly large repository, it should be possible to minimize the
time where developers don't have access to a repository if you plan the
migration carefully (and make a few vss2SVN trial runs before you do the
migration for real). For example, you can do it overnight or over the
weekend, depending on repository size.

ciao
Martina

  _____

From: Tom Malia [mailto:tommalia@ttdsinc.com]
Sent: Sunday, March 18, 2007 6:28 PM
To: 'Subversion Users mailing list'
Subject: RE: GUI Diff on Repository HEAD and "a" directory?

Comparing to pure file system for a couple of reasons.

First, I'm trying to transition from VSS to subversion and during the
transition, I sometimes need to compare what's been going on in VSS "working
directories" to what's currently in subversion repositories for the same
project or a branches of a project (one branch might still be managed VSS
while I'm try to transition the trunk toSVN for example). Going forward
this obviously, hopefully won't be the case, but will be for a reasonable
period of time right now.

Second, in an ideal world, source code would never end up out side a managed
directory. then there's the real world. at least in my company. Copies of
projects end up in non-managed folders or get sent to someone that doesn't
have SVN and the .svn directories get removed then the files get sent back.
etc. etc.. In general there are just times when such scenarios occur for a
variety of different reasons in the world in which I work.

The above scenarios kind of brings up another question.... Is there an easy
way to just copy over an un managed copy of a project tree into a managed
copy of the same project? For example, let's assume I have a project that
has a structure like:

Proj_Root

|_Lib

| |_SubLib01

| |_SubLib01_file1

| |_SubLib01_file2

| |_SubLib02

|_Headers

| |_Header_File1

| |_Header_File2

|_Etc.

|_Etc.

So if I've got the above structure for a project that's currently being
managed in VSS and accessed by 3 programs. but I'm also trying to move this
to SVN so I build a repository for it. Now, I check the project out of SVN
and decide I want to just completely replace the current version from SVN
with a version from one of the programs directory that was originally
checked out from VSS (so theirs doesn't have any .svn subdirectories
obviously). The Simplest solution would be if I could just copy the other
programmer's project tree into the SVN working directory, then check it all
back into SVN. The problem is when you copy the non-svn tree into the SVN
working directory, it deletes the .svn folders so when I go to check it all
in, everything gets treated as unversioned stuff.. What I'm looking for is
an easy ways to replace everything in the SVN working tree EXCEPT for the
.SVN folders. I've managed to do this by just copying files one directory
at a time and that worked, but it was very tedious.

Regarding you comment about doing a compare entirely within the repository.
is this something that is supported in TSVN? There are times when I want to
do what you have described here (though I think I need to do a lit reading
about "tags" verses "Branches"). However I don't remember seeing anything
is TSVN that lets me perform a GUI compare between items within a
repository.

  _____

From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Sunday, March 18, 2007 10:51 AM
To: Tom Malia
Cc: Subversion Users mailing list
Subject: Re: GUI Diff on Repository HEAD and "a" directory?

On 3/18/07, Tom Malia <tommalia@ttdsinc.com> wrote:

VSS's Diff program appears to be built into the client GUI (when I run it I
don't see any separate EXE's in my task list for it). When you do a Diff,
for each file/directory you want to compare you first decided if the source
is a file system source or a repository source. I find this feature VERY
handy. However, as you said, over a WAN the performance can be less than
ideal.. I guess you can't have your cake and eat it too. I can envision
creating some batch files or something that might make it easy enough to
utilize the export feature you mentioned just prior to performing an actual
Diff so that to the end user they don't really know the difference. However,
I again may be coming at this the wrong way..

Just to come back to this once more, I do think it is possible you are
coming at this from the wrong way.

Why do you need to compare repository contents against pure file system?
Are people modifying files outside the scope of version control?

If the file system is just a deployed version of your application and you
are just looking to compare that version against the latest version, then
why are you just not using tags? Everytime you deploy you just create a tag
in Subversion, and when you want to compare you can do the compare entirely
within the repository by comparing the tag against the latest version, or
whatever it is you want to compare.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/