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

On "Offline commits" and why they should be piloted in TSVN

From: Stefan Fuhrman <stefanfuhrmann_at_alice-dsl.de>
Date: Fri, 12 Feb 2010 03:50:56 +0100

This post has in a way be inspired by Hyrum's
"Subversion in 2010" post.

Having implemented a couple of scripts that provided
me with limited "offline commit" support, they never
were ad-hoc usable as they required local repositories
etc. So, I'm all in for a svn client implementation
of said feature.

Reactions to a recent post on the TSVN dev list made it
obvious that I need to give a *lot* more explanations
of why and how that might work.

Background

    Distributed VC is ultimately about independence
    (from infrastructure availability, performance
    and policies). In fact, SVN already supports many
    distribution use-cases through server-side proxies,
    working copies not being tracked by servers as well
    as working-copy-only operations.

    SVN changelists already allow for grouping changes
    to different files without committing them.

    However, the current working copy implementation
    is limited to a single modification per file, i.e.
    if two independent changes would affect the same
    file, a commit to the repository server is required
    in between the development of these changes.

    Current solutions like svn-git lack integration
    with an SVN client, i.e. they can't use the "offline
    commit" feature as part of SVN.

Use-case(s)

    High priority: The user shall be enabled to make
    multiple changes to the working copy without the need
    to contact the repository. Each of these changes may
    involve multiple files and different changes may
    affect the same file. Eventual limitations to the
    operations (e.g. renames, deletions etc.) possible
    off-line should be as small as possible.

    High priority: From the user's perspective, he/she
    is done with a change after an "offline commit".
    Therefore, the respective changes should not be
    listed in "svn st" anymore.

    Medium priority: A user might have made "offline
    commits" because he/she wasn't sure whether the
    change should be "published". So, it should be
    possible to undo offline commits. The respective
    changes should then again be visible as ordinary
    modifications in the working copy.

    Lower priority: As long as changes have not been
    committed to the repository, the user should be able
    to manipulate them. That would also allow to commit
    only a part of a file change within a given revision.

Possible solutions

    At least 3 different technical approaches may address
    the use-cases.

    (1) A patch recorder. Offline commits store data
        in svn diff / svn patch format.

        + basic functionality is easy to implement
        + robust patch handling (can be mailed etc.)
        + patches are easy to manipulate

        - bad integration with existing structures
          (working copy, repository) -> high maintenance
          effort for fixing edge-cases
        - svn st gets harder to implement
        - maybe: complicated update / merge / commit
          mechanisms for patches (i.e. publishing offline
          commits to the server)

    (2) Sparse, local, temporary (?), repository. This is
        the typical DVCS approach.

        + most generic approach (allows for whole hierarchies
          of servers and repositories)
        + logical extension to the existing infrastructure
        + potentially lowest limitations to operations
          possible

        - revision number is no longer a unique identifier
          for all users -> disruptive change
        - local repositories could become large since
          incoming data would probably be cached as well
          (for revision / ID mapping etc.). I.e. additional
          repo management code is required.
        - since repository structures will be affected,
          bugs will tend to have severe impacts

    (3) Deepen the working copy. Instead of only storing
        one pristine copy and one current content, an
        arbitrary number of intermediate contents can be
        stored.

        + logical extension to the current working copy
        + best integration in existing client logic
          (e.g. status and behavior upon update)
        + robust (WORKING and BASE retain their current
          relation to the repository)
        + relatively low implementation overhead; staged
          delivery possible (allow deep w/c for more and
          more operations).

        - wc-ng is currently in a flux; extensions should
          wait until it has settled.
        - the w/c content addressing scheme must be extended
          (e.g. "WORKING", "WORKING-1", etc. where "-x"
          would probably be a w/c-*global* number and
          reflect the number of outstanding /offline commits)

    Given that assessment, solution (3) would be preferable,
    followed by (1). (2) seems to imply an entirely different
    VCS at the end of the process.

Prototyping is necessary

    As a centralized VCS based on globally unique revision
    numbers, DVC with Subversion may face other challenges
    than typical DVCS. In particular, their solutions to
    certain problems may not be suitable / acceptable in
    the Subversion context.

    Therefore, before coming up with some final design
    proposal, it is necessary to gain some real-world
    experience with an "offline commit" prototype for SVN.

    (a) Usability, required features.
        - When and in what order will offline commits
          be pushed to the repository?
        - How want users to manipulate offline commits
          before send them to the repository?
        - What kind of changes (A/M/D/R etc.) must be
          supported to what extend (once, indefinite)?
        - What kind of operations should *not* be
          supported (e.g. empty queue before merge)?
        - Would hooks be useful?

    (b) Interaction with other features.
        - (Tree and other) conflicts upon update.
        - Conflict handling upon commit.
        - Impact of and on merges, renames, copies etc.
        - Interaction with svn switch and svn up -r

    (c) Expectations of DCVS users.
        - How can SVN support git / hg / .. users that
          find themselves in an SVN environment?

    Hopefully, some of these questions would be answered
    by the feedback of early adopters and the experience
    gained from the prototype implementation itself.

Why not pilot in SVN?

    Ideally, (3) would be implemented on some branch
    and a first incarnation be available around 1.7.
    However, with wc-ng in the flux, this means a much
    larger effort then working on a "settled" code
    base.

    Furthermore, a command line user interface is hard
    to design when the feature is not yet fully understood.
    Once defined, many user scripts will rely on it and
    it may be hard to change - despite its prototype status.

    There is even a chance, that 1.8 will focus on ironing
    out quirks and performance issues pushing the next
    "big thing" implementation to 1.9. Given the "big
    things need 2 versions to mature" experience with
    merge tracking support, this seems to be even a
    realistic scenario. NOTE: this is in no way meant to
    blame anyone - good things just take time.

    With 1.9 being maybe 2 years away, we should consider
    alternative paths. A good pilot available around 1.7
    would deliver enough input until the 1.8 release for
    the 1.9 development to start with "the real thing".

What would be the benefit of a TSVN-based pilot?

    TSVN seems to be the client that is used the most,
    also in corporate environments. Since this is about
    how to *integrate* the feature, a TSVN-based prototype
    would reach the largest audience. Also, a visual
    feedback may be more helpful for users to reason
    about priorities, workflows, missing features etc.

    Only the second-best approach would be feasible,
    but (1) is also the one easiest to implement and
    with the lowest immediate impact on other features.

    Questions that can be answered by using (1) comprise
    everything of (a), some of (b) and (c). In particular,
    it should give a good gauge for how restrictive the
    feature might finally be implemented if need be.

Temporary nature to the prototype

    The prototype functionality will not be available
    after SVN itself provides a similar feature.

    Because approach (1) is purely user-local with
    little on existing workflows, the impact of dropping
    it at any time is quite small.

Feature proposal

    A short description can be found here:

    
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Notes/FeatureProposals/Cleanup.txt

    (username: guest, leave password empty)

Comments?

-- Stefan^2.

             
Received on 2010-02-12 04:07:07 CET

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