Loosely Related Issues with Subversion



Changelist UI Improvements

Subversion's changelists feature is very simplistic; I find it barely functional enough to be useful. Recently I tried using a changelist to "stage" a commit of some new files in a WC where there were other unrelated changes which I wanted to leave in place, and I noticed the lack of ability to do simple things like 'svn add' a bunch of files and add them to a changelist in one operation. Here are some ideas along those lines.

When I apply a patch, I may want to add all the touched files to a changelist so that I can later commit or revert them easily, while leaving some previously modified files alone. I should be able to do that with one command:

    svn patch --add-to-changelist=foo ...

The same for any kind of change using an 'svn' command. There is an open question in what to do when the path concerned was already in a different changelist, as presently there can be only one changelist per path.

When I modify files, there is no svn command. Then, I may want to assign all modified files that are not already in a changelist:

    svn changelist foo -R --changelist=<none> --modified-files-only

How could I get modified files added to a changelist automatically? By defining an "active" changelist. (This is getting into the territory of Quilt or Mercurial Queues.) The paths not in any changelist act somewhat like an unnamed changelist is active, already, but there is currently no UI for selecting it, and there should be.

If I work with locking and changelists, I may want to lock all files in a changelist:

    svn lock --changelist=foo

When I lock additional files I may want to add them to the changelist:

    svn lock --add-to-changelist=foo PATH...

That's still pretty cumbersome if I regularly want to handle all the files I'm working on in the same way. I may want locking to be associated automatically with changelist membership. Adding a path to a changelist locks the path; removing a path unlocks it. If a lock/unlock attempt fails because the server is not responding, the state is remembered and can be reconciled later. Perhaps shelving a changelist unlocks its files, and unshelving locks them. A changelist/shelf remembers two configuration bits: "automatic locking" and "unlock when shelved". (UI for controlling it?)

Concrete, simple improvements:

  • An '--add-to-changelist=foo' option for all commands that affect WC paths:

    • svn add/mkdir/cp/mv/rm/lock/merge/patch/propset/...
    • --add-to-changelist=foo

  • To select versioned paths to operate on, the same selection options work in every command:

    • svn ci/cp/rm/di/export/info/ls/lock/log/mv/prop.../resolve/revert/shelve/st/up/...
    • PATH...
    • [--targets=]
    • [--depth=]
    • [--changelist= ...]

  • A CLI syntax to select paths that are not in any changelist.

  • The '--keep-changelists' option to 'commit' should also be available on 'revert'. (And 'shelve'?)

  • The '--keep-changelists' option to 'commit' should also be available as a config setting.

  • Assigning a moved file to a changelist should also assign its moved-from path.

  • A way to list the changelists:

    • svn changelist --list
  • 'svn status' without '-v' should not show unmodified files; currently it does in changelists.
  • 'svn info --show-item=changelist' (r1869481)

API to Export Data from WC

For 'repo-backed checkpointing' mock-up, I needed to get a copy of the WC 'base' tree out of the WC and into the newly created local repo.

There is no API for directly reading a whole tree from the WC.

A good one to provide would export either base or working version from the WC to a standard 'delta editor', something like this:

/*  */
svn_wc_export(const char *from_abspath,
                     enum svn_opt_revision_kind revkind,  /* base or working */
                     svn_depth_t depth,
                     const svn_delta_editor_t *export_editor,
                     void *edit_baton,
                     ...);

Then svn_client_export5() should use that instead of its internal implementation. (As a side effect, this will clean up some anomalies that exist in the current implementation.)

An issue noted in the existing code (comment in export_node()) is with the meaning of "base": according to the comment, it means the "new" (copied/moved/replaced) node's copy-from source, or none if not copied, rather than what was checked out at this path. Not sure if that is correct. For this API, "base" should mean what was checked out at each path.

New "log" API in repos layer, not yet in RA and client layers

The newest repos log API (svn_repos_get_logs5(), new for 1.10) sends changed paths streamily.

This is not yet available in the RA layer API.

The conversion function embedded within the deprecated API could be exposed for other consumers.

  • No labels