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.
