You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Magnus <ac...@zulutime.net> on 2009/02/10 19:55:17 UTC
[PATCH] Redesign of functional specification for obliterate
Attached is a patch to obliterate-functional-spec.txt, that takes an important first step in redesigning the specification to clarify it and hopefully get it closer to "implementability".
I submitted the main addition (a formal definition of the obliteration operation) to the mailing list some days ago, on the following thread:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1108134
There were no real objections then, but if there are any I would be more than happy to hear of them.
I would of course also appreciate hearing from any developers who agree with me that these changes are moving the specification in the right direction, since a specification is only useful if people would like to see it implemented.
Best,
Magnus
Re: [PATCH] Redesign of functional specification for obliterate
(Reposting extended patch)
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Mar 03, 2009 at 06:27:57PM -0500, Magnus Torfason wrote:
> I'm posting an updated patch to the svn obliterate functional
> specification. The patch is getting a bit big (670 lines), and
> it is only going to grow bigger as I continue working on this,
> so it seems proper that it gets some review before I go much
> further. What would be the process for getting this kind of
> patch committed into the repo? Votes, comments, consensus?
Just a low-priority drive-by remark:
The text uses the '+' character for bullet lists, which makes
a unidiff of the text a bit confusing to read.
Could we switch the text to use some other character (like '*')
instead, in a separate patch?
Thanks,
Stefan
Re: [PATCH] Redesign of functional specification for obliterate
(Reposting extended patch)
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 4, 2009, at 2:57 PM, Stefan Sperling wrote:
> On Tue, Mar 03, 2009 at 06:27:57PM -0500, Magnus Torfason wrote:
>> What would be the process for getting this kind of
>> patch committed into the repo? Votes, comments, consensus?
>
> There is no formal process as such.
>
> Your earlier posts about obliterate have received lots of comments,
> so it's reasonable to assume that this patch will trigger some further
> discussion.
>
> I'd say we'll wait a while for some comments, and if the general vibe
> during the discussion is positive, we'll commit this update to the
> spec.
> If no comments arrive, we'll see what we can do about that.
>
> While I myself have not yet concerned myself enough with "obliterate"
> to be able to provide useful comments, I am glad to see you trying
> to push this long-standing issue forward and would hate to see this
> contribution end up being dropped.
I went ahead and committed the patch in r36503. Although I didn't
read it thoroughly, and I don't have time to push the obliterate work
forward, I think we can iterate on the design in the repo instead of
the mailing list. Getting this committed is a step toward that end.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1313001
Re: [PATCH] Redesign of functional specification for obliterate
(Reposting extended patch)
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Mar 03, 2009 at 06:27:57PM -0500, Magnus Torfason wrote:
> What would be the process for getting this kind of
> patch committed into the repo? Votes, comments, consensus?
There is no formal process as such.
Your earlier posts about obliterate have received lots of comments,
so it's reasonable to assume that this patch will trigger some further
discussion.
I'd say we'll wait a while for some comments, and if the general vibe
during the discussion is positive, we'll commit this update to the spec.
If no comments arrive, we'll see what we can do about that.
While I myself have not yet concerned myself enough with "obliterate"
to be able to provide useful comments, I am glad to see you trying
to push this long-standing issue forward and would hate to see this
contribution end up being dropped.
Stefan
[PATCH] Redesign of functional specification for obliterate
(Reposting extended patch)
Posted by Magnus Torfason <zu...@gmail.com>.
I'm posting an updated patch to the svn obliterate functional
specification. The patch is getting a bit big (670 lines), and
it is only going to grow bigger as I continue working on this,
so it seems proper that it gets some review before I go much
further. What would be the process for getting this kind of
patch committed into the repo? Votes, comments, consensus?
Best,
Magnus
[[[
Improving the specification of svn obliterate (issue #516)
* notes/obliterate/obliterate-functional-spec.txt
Numerous changes to the functional specification.
The table of contents for the file is as follows:
0. TABLE OF CONTENTS
1. INTRODUCTION
1.1. Use Case Overview
1.2. Current Solution
2. DEFINITION OF THE OBLITERATION OPERATION
2.1. Supporting Definitions
2.2. Main Definition
2.3. Notes
3. DIFFERENT TYPES OF (CORE) OBLITERATION
3.1. ABSOLUTE vs. VIRTUAL obliteration
3.2. ONLINE vs. OFFLINE vs. REPO-INVALIDATING
4. LIMITATIONS ON THE OBLITERATION SET
4.1. Obliteration of Deletions (is forbidden)
4.2. Obliteration of the HEAD revision (is forbidden)
5. USE-CASES IN DETAIL
]]]
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1263812
RE: [PATCH] Redesign of functional specification for obliterate
Posted by "Magnus ..." <ac...@zulutime.net>.
I unfortunately forgot to place the suggested
commit message in my last post.
Here it is:
[[[
* notes/obliterate/obliterate-functional-spec.txt
Add section formally defining obliteration functionality
Make various changes to the use case listing up front
Make a few formatting changes
Make a few updates to the individual operations listed
]]]
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1136259