Hmm... It's close, but the limitations on only assigning one per file are a bit onerous; it's very often in the same file that I'm working on that I find bugs, etc., that I want to commit separately.
Randon
From: Chris Shelton [mailto:cshelton_at_shelton-family.net]
Sent: Wednesday, December 21, 2011 5:28 PM
To: Randon Spackman
Cc: users_at_subversion.apache.org
Subject: Re: Request for thoughts on working copy enhancement request
Randon,
On Wed, Dec 21, 2011 at 3:10 PM, Randon Spackman <Randon.Spackman_at_hotdocs.com<mailto:Randon.Spackman_at_hotdocs.com>> wrote:
One of my common use cases for subversion is to want to split my changes into two separate commits. In the past, I would do the following:
1) Check out
2) Make changes
3) Realize that this should be more than one commit
4) Copy directory "MyCode" to "MyCode2"
5) Revert changes I don't want to commit yet from "MyCode2"
6) Commit "MyCode2"
7) Delete "MyCode2"
8) Update "MyCode"; already committed changes are merged and no longer appears as diffs.
9) Commit remaining changes in "MyCode"
Unfortunately, this use case is defeated by the 1.7 changes to a single .svn dir. My current workarounds are as follows:
1) Copy the entire working copy (multiple GBs, waste of time), or
2) Do an "svn info" to get repo and revision, then check this out somewhere to obtain the necessary ".svn" folder which is then copied to "MyCode".
Neither of these is very elegant. I'd like to see a new svn command such as "svn localize" (don't keep my terminology if it sucks) that would make the directory you specify its own independent working copy that can be copied and manipulated individually, and possibly a "svn delocalize" to reintegrate it. (Although this can be accomplished less effectively by simply deleting the ".svn" directory and doing an update.)
Is there already a way to do this? Thoughts?
This sounds like a good case to use changelists. See:
http://svnbook.red-bean.com/nightly/en/svn.advanced.changelists.html
for details.
chris
Received on 2011-12-22 01:32:09 CET