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

RE: default version control for all adds/deletes/renames in working copies

From: Mike Craig <Mike.Craig_at_freeclear.com>
Date: 2006-05-03 22:45:57 CEST

Hm. Sounds like you want StarTeam. (did I just say that?)

 

________________________________

From: Gillis, Paul [mailto:pgillis@insight-tek.com]
Sent: Wednesday, May 03, 2006 1:32 PM
To: users@subversion.tigris.org
Subject: default version control for all adds/deletes/renames in working
copies

 

Perhaps I've overlooked something that's been explained in the
documentation or the mailing list archives, but I've been unable to find
a good answer to my issue. Maybe somebody out there can enlighten me.

 

My company has agreed we need version control and I convinced them we
should adopt Subversion. I am in the process of taking lots of
different uncontrolled software releases and putting them into
repositories in a logical chronological manner. I could just do imports
and dump everything in there all at once. But I'm trying to preserve
the revision change history and evolution of each project so it can be
easily understood by anybody new to Subversion simply by reading the
commit logs and seeing how named release tags get created from specific
revisions of the evolving trunk. I'm hoping people new to subversion
will recognize these as examples of best practices to follow.

 

I start by creating the usual /trunk /branches /tags structure and I
import an initial set of data into the trunk. I then make a working
copy of the trunk. Next I copy a named release tag from the head
revision of the trunk. So far, it's easy! And I'm left with a working
copy that matches both the head revision of the trunk and the named
release tag.

 

Now the trouble begins! Very often, the next revision of the way the
software needs to look in my trunk requires directories and files to be
renamed as well as other files and directories to be added and deleted.
To modify my working copy for next revision commit to the trunk, I use
WinMerge to compare my working copy against what the next release is
supposed to look like. When files of the same name exist but are
different, WinMerge lets me easily copy the new files into my working
copy and Subversion knows by default the file has been modified and it
will be updated in the trunk when I do the next commit. But any NEW
files I want to WinMerge into my working copy and any files I want to
DELETE or RENAME from my working copy require me to use Subversion
commands to ADD, DELETE, or RENAME them under version control. I can't
just do it once directly and easily with WinMerge. I have to also use
subversion or TortoiseSVN commands to perform these operations so they
are recognized under version control. I find this very tedious. What I
want Subversion to do is assume that ANY file or directory deletion,
addition, or rename in my working copy should automatically be
considered for version control when I do my commit! I want that to be
the default behavior. I don't want it to ignore all those changes I
made to my working copy. It doesn't seem that unreasonable to me. And I
find it hard to believe others wouldn't also want this to be the default
behavior in many circumstances

 

Is there a setting or any easy way to do this? I don't want to write
scripts that have to do diffs and then parse the output to do svn adds,
deletes, renames like I saw discussed in an earlier thread.

 

Thanks for any suggestions!

 

Paul Gillis

pgillis@insight-tek.com <mailto:pgillis@insight-tek.com>

 

________________________________

This e-mail message and all attachments thereto may contain technical
data that is subject to export control regulations, or confidential
material, and is for the sole use of the intended recipients. Review,
dissemination, or other use by anyone else is prohibited. If you are not
an intended recipient, please contact the sender and delete all copies.
Received on Wed May 3 22:47:17 2006

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.