Hey,
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
copy.
* 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
(reverting).
* 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
revision.
* 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.
Comments?
Gr.
Matthijs
---------------------------------------------------------------------
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