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

  _____

From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Sunday, March 18, 2007 12:54 PM
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:

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.

I don't know, this does not sound like a real world example to me. I am not
saying it does not happen, it just does not sound like a justifiable
situation that someone ought to be looking for coding solutions to try to
solve. Did it perhaps happen in the past because people did not like
SourceSafe and did not want to use it, or it did not work well remotely or
something. I cannot see why someone using SVN would do this. I mean I can
see someone tweaking a web page on the fly, but why would someone do this
with C (pick your language) source code? If it happens, then use export to
create a representation of what is in SVN and then diff the folders.

[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.

Another occasional scenario occurs when we need to ship a project's source
code off to an outside consultant to deal with particular problem or
something and that outsourcer doesn't have SVN, so we package the
development directory up, send it off and when it comes back with the
desired correction, it also comes back without the .SVN folder. again, not
ideal but these are the kind of things that happen.

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.

On Windows, I did not think copying the folders over the top would delete
the .svn folders. People have written scripts to do this sort of thing.
Usually because they wanted the intelligence of detecting delete and adds,
and maybe copies to a limited extent. Look around for cases where people
are trying to mirror a 3rd party source tree in the repository, because that
is essentially the same scenario.

Subversion 1.5 will allow you to checkout a project with the --force option
and overlay an existing project on disk. Underlay might be the better term
because it will preserve existing files and just create the working copy as
needed. After the command completes the svn status and diff commands can be
used to examine the differences.
 

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.

Just select two items in the repository browser and right click. You can
produce a unified diff or the compare versions option will show you the
differences at the file level, and you can then drill-down for diffs.
 

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