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

Re: (SoC) Feature proposal: Patch-awareness

From: Matthijs Kooijman <m.kooijman_at_student.utwente.nl>
Date: 2005-06-13 00:03:17 CEST


after some more thought I think "Working copy changeset management" would be a
nicer name for this feature. I will, for now, let go of the patch uploading
part and concentrate on the working copy part.

What it will do:
* Allow you to have multiple different changesets within a single working
* Track each change in the working copy to a specific changeset.
* Designate one changeset as the "active" changeset, all new changes will
  belong to that changeset.
* Allow you to move changes from one changeset to another, or remove them alltogether
* Allow you to hide and reshow changesets, effectively reverting and
  reapplying them.
* Allow you to show differences in a specific change set compared to the base
* Commit changes from one or more changesets.
* Possibly, allow changesets to be shared by working copies in some way. I'm
  not sure if this is really useful yet.
* Allow you to intelligently apply a patch generated by "svn diff", by doing a
  three-way merge with the base revision of the patch. (optionally putting the
        patch in its own changeset).

Now, why would this be useful?
* If you are implementing a feature and fix some bugs at the same time, you
  can split them into different changesets and commit just the fixes before
        you finish the feature. This saves handediting diffs to separate changes.
* If you have a patch that enhances, for example, debugging capabilities but
  is not yet committed for whatever reason. You can then apply it, without
  having to remove it everytime you commit a feature.
* You can apply patches more cleanly when the base revision is known.

How will we implement this? This is the part where it gets a little fuzzy
again. Don't know what is best here yet.
* We could store a copy of all the working copy files that are changed by
  inactive changesets with that inactive changesets applied. This will allow
        for quickly generating a diff of the active changeset (Since the active
        changeset will include all new changes, it cannot be stored explicitely).
* As soon as the active changeset changes, we'll have to find out what has
  changed in it and store that explicitely.
* When we commit a changeset, we will have to find out what the changes in
  that changeset are in relation to the base revision (ie, we'll do lot's of
        offsetting of textdelta's).
* We can probably save each (inactive) changeset as a tree-delta that we
  can subtract from the actual working copy vs base rev tree-delta to find new
        changes. The subtracting needs some thought.
* This feature will mainly need changes in libsvn_wc and some in
  libsvn_client, but none in the other parts.

Well, so much for now I think.




To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 13 00:04:06 2005

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

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