Michael Sweet <mike@easysw.com> wrote on 09/17/2004 09:35:36 AM:
> All of this sounds like providing a way to save WC versions (a la
> VMS file versions) might be enough to track/save local changes until
> they can be commited to the main repo. Whether you store fulltext
> copies in the .svn/text-base directory
> (.svn/text-base/filename.svn-base.1, filename.svn-base.2, etc.)
> or deltas/diffs would be an implementation detail, but my thought
> is that the WC would essentially become a mini-repo that can track
> micro-changes...
Do we want full decentralisation, or do we just want something simpler,
like disconnected operation?
Seeing as we already have ra_local, could we have something like this?
$ mkdir ~/svn
$ cd ~/svn
$ svn co http://svn.collab.net/repos/svn/trunk
....
Checked out rev 3487534975
*********NETWORK CABLE PULLED**************
$ svn (localise|offline|disconnect|localbranch)
Working copy now using file:///tmp/localrepos
$ vi HACKING
$ svn commit
....
Committed rev 1
<some time later....>
********NETWORK BACK ONLINE*******************
$ svn (unlocalise|online|reconnect|(unbranch|upmerge))
[multicommit|singlecommit]
Replaying changes from file:///tmp/localrepos to
http://svn.collab.net/repos/svn/trunk
Committing rev 1 as 3487534976
Committing rev 2 as 3487534977
Committing rev 3 as 3487534978
Working copy is now using http://svn.collab.net/repos/svn/trunk
$ vi HACKING
....
$ svn commit
....
Committed rev 3487534979
Where:
svn localise - changes where the WC points, creates a local repository
and makes rev 0 look like the content of the WC.
svn unlocalise - commits your changes back to the main repository,
either
as a bunch of commits (taking your comments with them),
or as a single commit (and asks for a new comment)
I'm not sure how much info is stored in the WC, whether it's enough to
construct a local repository with enough info to enable sensible commits
back later on. "localise" might require connection to the main
repository
to get sufficient info, although it would be nice to just kick your
WC into local-only mode in case you decide you need to commit a change
when
you're halfway home on the train and forgot to "offline" yourself
before you left work.
The choice of command I leave as a bikeshed painting exercise.
Nothing special really, other than reducing "svnadmin create ; svn import
; svn co"
into a built-in command (maybe the reconnect feature is new and
exciting...)
What I think is nice:
1) local versioning, which lots of people seem to want
2) full capabilities on the local versioning thingy
3) you could potentially cascade these repository disconnections
What you don't get:
1) Patch management, any different to what we have right now
2) Full history in your local repository
3) Meaningful local revnums
What might be broken:
1) Conflict resolution, what happens when a conflict occurs half way
through
your set of revisions? Someone smarter than me needs to solve that
one.
If we can get enough information in the local repository about
node_revnums
then we might be able to follow ancestry and solve this the same way
that branch merges get solved. As hinted to in the model document
(design/model.texi), if the inter-repository merge problem is
solved,
then this one is too (maybe).
daniel
(apologies in advance for the signature that will undoubtedly be attached
to the bottom of this, and for the awful formatting I'm sure Lotus notes
will apply to this message after it enters SMTP land)
This email is sent by or on behalf of the named sender identified above. If
you do not wish to receive any email marketing material from this person in
the future, please forward the contents of this email to
unsubscriptions@national.com.au with the word "unsubscribe" in the subject
box. If you do not forward the contents of this email with your
unsubscription then it may not be able to be implemented. If you wish to
unsubscribe from all central email marketing lists used by our business,
please forward the contents of this email to
unsubscriptions@national.com.au with the message "unsubscribe from all
central email marketing lists" in the subject box. If you do not forward
the contents of this email with your unsubscription then it may not be able
to be implemented.
The information contained in this email communication may be confidential.
You should only disclose, re-transmit, copy, distribute, act in reliance on
or commercialise the information if you are authorised to do so. Any views
expressed in this email communication are those of the individual sender,
except where the sender specifically states them to be the views of a
member of the National Australia Bank Group of companies. Any advice
contained in this e-mail has been prepared without taking into account your
objectives, financial situation or needs. Before acting on any advice in
this e-mail, National Australia Bank Limited recommends that you consider
whether it is appropriate for your circumstances. If this e-mail contains
reference to any financial products, the National recommends you consider
the Product Disclosure Statement (PDS) or other disclosure document before
making any decisions regarding any products. The National Australia Bank
Group of companies does not represent, warrant or guarantee that the
integrity of this communication has been maintained nor that the
communication is free of errors, virus or interference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 17 04:44:37 2004