RE: Darcs-style interactive commits

I have some feature suggestions relating to this...

When committing a set of files (using Tortoise, for example), you may spend quite some time selecting a subset of the files. If the commit fails (perhaps due to a hook script) then there is no record of the selection made. (This would not be a problem with a command-line client commit, of course.)

That might seem off topic, or on the wrong mailing list, but I have a little detail to add.

I agree that it would be useful even to be able to "partially commit" files; that is, commit a subset of the changes made to each given file.

1I would love to see some features added to "svn commit":

[1] Commit Files and Properties

When no --message (or --file) is specified, and EDITOR opens for a commit message to be entered. This also shows the list of files. I'd like to see a couple of enhancements to this: I'd like to be able to force this action, even if a commit message is supplied. I'd also like to see the properties, in addition to the files, that have changed.

([1b] A bit off topic, it would also be useful to be able to get a summary of which properties have changed from svn status.)

([1c] Yet further off topic, and probably further from reality, I wonder why the design of SVN treats files and properties separately. This would be a *major* change, but perhaps property "ppty" of file "file.ext" in directory "dir/subdir" should be referred to in the svn file system just as "dir/subdir/file.ext/ppty". Then, there would be no reason why properties themselves could not have properties -- meta-meta-data. That would be useful when properties are used to store, for example, thumbnails of image files; these could have their own properties. I believe there would be many advantages to this approach. The system would need a way to distinguish a "property" from a "file", especially a property of a directory; perhaps it could be handled via a new node kind.)

[2] Commit Failure Dump

When a commit fails, it would be good to have a dump file (or, better, set of files) in the working copy created containing a list of files, the commit message, and the error message(s) from the client or server.

[3] Line Selection and Attaching a Delta

When committing, a set of files may be specified via the --targets option. It would be useful if you could attach a "delta" to a commit (using, e.g. a --delta option). Then, in order to commit a subset of your changes, you could create a delta with "svn diff", edit it, and then use this in a commit.

I don't have a good suggestion for how to deal with property changes. It could be done via the "delta" again, but perhaps there's a better way. Perhaps separate deltas per file, and per property, could be specified somehow (perhaps using a regex). Perhaps that's too complex.

On the other hand, the manual method outlined by Steve Strobel has the advantage that changes being committed can first be tested, which is good practice. An alternative approach to this is to have a second working copy set up, and to use a directory and file diff tool to copy or move a subset of the changes there. Following the commit, these changes may be "updated" to the original working copy.

Rob.

> -----Original Message-----
> From: Remko Troncon [mailto:public@el-tramo.be]
> Sent: 14 October 2006 08:40
> To: users@subversion.tigris.org
> Subject: Darcs-style interactive commits
>
>
> Hi,
>
> I was wondering if there were plans to add a flag to 'svn commit',
> that would cause svn to ask for every change in your working copy
> whether or not you want to add it to your commit. Darcs does this,
> and we have found this to be extremely useful for a number of things:
> - It is a good last-minute check that you are not committing stuff
> that you don't want
> - It allows you to quickly commit a fix while you are working on
> something else in your working copy
> - It allows you to leave in things like debug printf() messages when
> committing, and you just have to revert afterwards to get rid of them.
> - ...
>
> cheers,
> Remko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.

This email and any files transmitted with it are confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed. If you have received
this in error, please contact the sender and delete the material
immediately. Whilst this email has been swept for viruses, you
should carry out your own virus check before opening any
attachment. Celoxica Ltd accepts no liability for any loss or
damage which may be caused by software viruses or interception
or interruption of this email.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 6 17:45:27 2006