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

tagging externals

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Fri, 12 Feb 2010 20:20:11 +0100

Hi,

I've created a preliminary spec for how the 'tagging externals' feature
should work.

Please comment!

You can find it here:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Notes/Feature
Proposals/TagExternals.txt

(username: "guest", leave password empty)

Or pasted below:

Feature Proposal
================

Name

----
Patch Recorder
Chosen deliberately to not collide with the
feature that might be added to the SVN core
sometime in the future.
Common names for similar features:
* offline commits
* pre-recorded commits
* commit queue
Purpose
-------
Allow the user to perform a commit-like actions
without connection to the repository:
* select changes to commit ("recorded patch")
* assign commit comment
* review the change
* allow multiple recorded patches for the same file
* option to show w/c modifications as if the
   recorded patches had actually be sent to the
   repository
* commit pre-recorded patches to the repository
   upon user request
There are already solutions like svngit that allow
offline commits. However, these do not integrate
with SVN clients and may be limited wrt. to SVN
feature support.
Part of this experiment is to find out what
functionality is required for offline commits
and how that should integrate with existing
SVN features.
Functional Details
------------------
The following will be recorded per patch:
* list of file operations:
	- operation (A, M, R, D)
	- path
	- copy-from path
	- BASE revision (= copy-from rev for A)
	- isBinary flag
	- isFolder flag
* per changed node:
	- props + file content before patch
	- props + file content after patch
	  (patch / udiff files will be created
	   dynamically)
* a comment
* a time stamp
A patch will be recorded as follows:
* directly from "commit" dialog
* "record only" button or checkbox
* patch info is then created automatically,
   taking existing patches into account
Another option allows to show to only changes
not already covered by pre-recorded patches:
* new "exclude pre-recorded patches" checkbox
   in "commit" dialog
* patch recorder is asked for current status
   of every path. BASE content has to be passed
   in as well. Result is unchg / M / A etc plus
   BASE content after applying all patches
* op is used to reduce change list and to
   show diffs (simply a different BASE content)
Recorded patches can be inspected and modified
in the new "patch recorder" dialog.
* available from explorer context menu next
   to Commit entry (only available if there is
   at least one patch in the recorder)
* lists patches and their content similar to log
   dialog (but with fewer options / operations)
* patch manipulation
	- delete seleted patches
	- merge selected patches
	- split patch
	  (i.e move selected files to new patch)
	- edit comment
	- edit patch
	  (i.e modify "after" file via diff tool)
	- move part to previous
		modify "before" file via diff tool,
		make it the "after" file of prev. patch
	- move part to next:
		modify "after" file via diff tool,
		make it the "before" file of prev. patch
	- check integrity:
		mark patches with this_before (node) !=
		pervious_after (node)
* commit button commits selected patches
Committing recorded patches:
* update and commit dialog will try to contact
   the repository for the oldest patch. If the
   repo is available, ask user whether patches
   shall be uploaded. If "yes", the "patch recorder"
   dialog pops up.
* user (multi-)selects patches in "patch recorder"
   dialog and hits the "commit button"
* patches get committed in order of their timestamp,
   stop as soon as any user op was answered with
   "cancel"
* committing a patch:
	- create a temporary, sparse w/c covering
	  the changed paths
	- compare file contents & props against
	  the recorded "before change" data;
	  remember result as "merge was required"
	- replay changes
	- user must resolve conflicts immediately
	  (TMerge / user-defined merge tool)
	- if merge was required, ask user to review
	  change (bring up normal c/i dialog with
	  comment preset accordingly)
	- otherwise, commit automatically
	- delete temp. w/c
	- remove patch from recorder
* user has to update its w/c manually
TSVN Integration
----------------
The feature will be implemented on a branch of the
TSVN main development line as part of the TortoiseProc
project. Otherwise, numerous files needed to be
duplicated and were hard to sync etc.
Impact on existing TSVN functionality is kept low
by extending only a few selected dialogs. Furthermore,
these extensions are of the form:
	AddExtraButtons();
or
	CallNewFunctionality();
The deliverable will be an experimental build of the
otherwise unchanged 1.7 code. During installation,
the user will be asked to accept the conditions of
the "experimental" build. Standard and experimental
build cannot be used side-by-side with the same bitness.
Target Version
--------------
1.7
Proposed Status at First Release
--------------------------------
Experimental.
* N/A by default. Requires separate installation
* No commitment to support. Feedback welcome, though.
* No translations / NLS for the extensions.
* Limited documentation only (probably a README file).
* Feature will be removed in future versions
   as soon as SVN core grows a similar feature.
* Integration with TSVN will be rather incomplete.
* Error / edge case handling will be limited.
* Performance and functionality will be limited
   in comparison to a proper SVN feature.
* SVN core feature may differ greatly from the
   patch recorder.
Possible Development Stages
---------------------------
(1) Get patch storage up and running:
	- extend "commit" dialog with "record" button
	  and pass selected path list to recorder
	- store information in recorder but
	  *don't* take existing patches into account
	- basic r/o version of the p/r dialog
(2) Get commits working:
	- add diff operation to p/r dialog
	- add "commit" button to p/r dialog and
	  perform commits as described above
	  (will often require merges and resolving
	  false conflicts)
(3) Add BASE / status combination logic
	- implement (path, rev, BASE content, content, status)
	  -> (new BASE content, new status)
	- use that to extend patch creation logic
	  to store only new changes
	  (commits should now work smoothly)
(4) Complete the TSVN integration
	- "exclude p/r" option in "commit" dialog
	- automatically ask for p/r commits in
	  update and commit commands
(5) Patch modificaton
	- finalize p/r dialog
Stefan
-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2447156
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-12 20:20:22 CET

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

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