Re: Request for thoughts on working copy enhancement request
Randon, On Wed, Dec 21, 2011 at 3:10 PM, Randon Spackman < randon.spack...@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
Re: Request for thoughts on working copy enhancement request
Sounds like a feature much like git's "git stash" On 21 December 2011 20:10, Randon Spackman 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? > > > > Randon Spackman
RE: Request for thoughts on working copy enhancement request
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:cshel...@shelton-family.net] Sent: Wednesday, December 21, 2011 5:28 PM To: Randon Spackman Cc: users@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 mailto:randon.spack...@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
Re: Request for thoughts on working copy enhancement request
On 12/21/2011 4:31 PM, Randon Spackman wrote: 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 Normally I have one "main" sandbox and one "quick updates" sandbox. The latter doesn't get used very often - only when I need to fix something quickly while the code in the main sandbox is in an unstable state. Updating this backup sandbox takes much less time than a full update, and my machine is not so small that a few gigabytes of duplicated storage would fill it. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Request for thoughts on working copy enhancement request
On Dec 21, 2011, at 14:10, Randon Spackman wrote: > 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, This function has been called "detach" here before and is implemented in this script: http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/detach.py Here's the issue requesting a proper svn command for this: http://subversion.tigris.org/issues/show_bug.cgi?id=2884 > 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.) I'm not aware of any work to make this possible.
Re: Request for thoughts on working copy enhancement request
On Wed, Dec 21, 2011 at 12:10:26PM -0800, Randon Spackman 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?
Others have already pointed out the 'detach.py' script you could use.
I'd like to add that 'svn patch' (new in 1.7) has been written with this
use case in mind. Whenever I realize I'd like to split up my changes into
more than one commit I use this approach.
Save the output of 'svn diff' to a file and apply it with 'svn patch' later.
This works for most types of changes. Be careful with copies (translated to
plain adds by 'svn patch') and mergeinfo changes (not applied by 'svn patch').
Any other changes to file content, structure or svn: properties are retained.
'svn patch' skips changes listed in the patch file which are already present
in the patch target, so most of the time saving the full diff to a patch file,
undoing some changes, comitting, and then applying the saved patch works fine
if all you want to do is commit a subset of your local changes.
If 'svn patch' runs into conflicts (e.g. because before commit you edited a
line saved away in the patch) it produces reject files. Cleaning up those
rejects manually can be tedious. But rejects can be avoided if you follow
this hint from 'svn help patch':
Hint: If the patch file was created with Subversion, it will contain
the number of a revision N the patch will cleanly apply to
(look for lines like '--- foo/bar.txt(revision N)').
To avoid rejects, first update to the revision N using
'svn update -r N', apply the patch, and then update back to the
HEAD revision. This way, conflicts can be resolved interactively.
Once you feel comfortable working with patches you can also do some
fixups by editing the patch file before applying it, throwing out or
tweaking individual changes ("hunks" in patch terms) of the patch.
E.g. sometimes I save two copies of the same patch and then edit both
copies to produce two distinct changesets. This works because 'svn patch'
is quite tolerant and tries its best to apply changes even if lines of
code have been moved around in the target or if the line offsets recorded
in the patch don't match anymore.
Of course, none of this comes very close to the convenience of a real commit
shelving feature (like 'git stash' already mentioned in this thread).
There is an open request on our tracker to implement commit shelving as a
first-class subcommand ('svn shelve' or 'svn stash'), see
http://subversion.tigris.org/issues/show_bug.cgi?id=3625
You might want to add yourself to the Cc list there to keep informed
about progress. AFAIK nobody is currently working on this though.
As usual, everyone is welcome to jump in and have a go at it :)
