[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Tom Malia <tommalia_at_ttdsinc.com>
Date: 2007-03-18 18:28:15 CET

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/ 
Received on Sun Mar 18 18:27:52 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.