You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@subversion.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2004/04/01 00:52:28 UTC

Re: Roadmap for 1.1 [placeholder]

--On Wednesday, March 31, 2004 5:07 PM -0600 David Summers 
<da...@summersoft.fay.ar.us> wrote:

> Is true 'move' (not cp;rm) on anybody's radar screen at present?  Is that
> very difficult or would that be pretty difficult and/or something to put
> in 2.0?

Sussman's item about 'make subcommands follow copy history' is geared 
towards resolving this by modifying our interfaces to be sane about 
tracking moves properly.  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by Neil Schemenauer <na...@arctrix.com>.

kfogel@collab.net <kf...@collab.net> wrote:
>     * True rename support, at least in the repository

Yes please.

>     * symlink support

Nice to have.

> Are there other things you would like to see on this list?

Everything else on your list I don't care about.

  Neil


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by Greg Hudson <gh...@MIT.EDU>.

On Wed, 2004-03-31 at 21:41, kfogel@collab.net wrote:
>     * l10n (also known as i18n or "that gettext thang")
>     * Locking (reserved checkouts)
>     * Issue 1093 and friends (diff-follows-copy-history, etc)
>     * Straighten out Java bindings
>     * Improved release procedures & scripts
>     * Full DeltaV compliance (called "pie in the sky" :-) )
>     * In-repos ACLs (may be intertwined with reserved checkouts work)
>     * True rename support, at least in the repository
>     * symlink support
>     * "What about plug-in client-side diffs?"
>     * Fix N specific bugs (many in issue tracker are already marked as
>         "1.1", though that set is not written in stone of course)

If you throw in merge-tracking and distributed operation, you've got
just about all of our wishlist there.  That's not much of a roadmap, in
that it doesn't help us decide when we're ready to make a 1.1 release. 
(Nor does it tell developers what to focus their efforts on, but I doubt
many developers are interested in such guidance anyway; we all have our
pet interests.)

I think the right way of thinking about this problem is:

  * What features would make a 1.1 release interesting?
  * Are any features absolutely essential for 1.1?
  * When do we want to target a 1.1 release for?

Something like three months before the 1.1 target date, we need to look
at what's ready to go and cut bait on the rest, since we'll want to
branch and go into beta testing around two months before the target
date.  If we don't have at least one of the "interesting enough"
features by then, or if we don't have any of the essential features (but
are making progress on them), then we delay.  If 12-18 months go by and
we *still* haven't finished anything interesting, then we should decide
that we've stalled and release a 1.1 with minor improvements, but that
seems pretty unlikely.

I'm not going to call any feature absolutely essential for 1.1, myself. 
Of the features listed above, I'd say the ones that would each make a
1.1 release worthwhile by themselves are:

  * Locking
  * Java bindings
  * In-FS ACLs
  * True rename support

But true rename support may be too hard to implement in a fashion that's
acceptable for 1.x, and it's probably too hard for this time frame
anyway.  Likewise, libsvn_fs_fs, libsvn_fs_sql, history-sensitive
merging, or distributed operation features would be interesting enough
for 1.1, but I don't anticipate any of them happening in that timeframe.

As for features which are neither "interesting enough" nor "essential,"
the 1.1 roadmap isn't supposed to discourage anybody from working on
them, although other factors might.  For example, symlink support would
complicate a libsvn_wc which cannot really tolerate more complication,
so first we'd have to kick off a redesign effort, and maybe we'd rather
not do that while we're trying to implement locking and FS ACLs and
localization and libsvn_fs abstraction and a few of us are working on a
new FS layer.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by "Philip W. Dalrymple III" <pw...@mdtsoft.com>.

We would (my company) would like to see the keyword support expanded,
best would be the full, flexible, user defined keywords but at least the
$Header$ expansion (a different format of the info in $Id$ but the one
we have used in CVS for 8 years or so).

If I have to I can either switch to $Id$ (and fix a bunch of scripts
that are dependent on Header) or patch subversion to support Headers. I
know that others have said that because the keyword system needed a
major rework nothing should be done for 1.0.


On Wed, 2004-03-31 at 21:41, kfogel@collab.net wrote:
> Hmmm.  You know what?  Let's just have the roadmap discussion here.
> 
> I've removed the "[placeholder]" bit from the Subject line, but left
> other threading metadata intact.
> 
> Originally, I had wanted to come back to the list with a beautiful,
> shiny, detailed proposal with lots of justifications and subpoints and
> whatnot.  But the responses so far show that many people *already*
> have ideas for 1.1.  Therefore, it's probably better to figure out the
> roadmap iteratively on this list (Greg Stein suggested the same in a
> private mail).  Sure, it may take longer, but everyone will have a
> stake in the final result.
> 
> Here's what we've got so far.  If I left anything out, it's only by
> accident, please follow up with the missing item.  I haven't attached
> the names of the suggesters, since it's the suggestions themselves
> we're interested in:
> 
>     * l10n (also known as i18n or "that gettext thang")
>     * Locking (reserved checkouts)
>     * Issue 1093 and friends (diff-follows-copy-history, etc)
>     * Straighten out Java bindings
>     * Improved release procedures & scripts
>     * Full DeltaV compliance (called "pie in the sky" :-) )
>     * In-repos ACLs (may be intertwined with reserved checkouts work)
>     * True rename support, at least in the repository
>     * symlink support
>     * "What about plug-in client-side diffs?"
>     * Fix N specific bugs (many in issue tracker are already marked as
>         "1.1", though that set is not written in stone of course)
> 
> Let's not get down to actual voting or anything like that at this
> point.  And, let's not talk about dates just yet.  Rather, let's start
> with some questions:
> 
> Does anyone see anything on this list that looks hard or impossible,
> given our API guidelines, for a 1.1 release?
> 
> Do we think anything on this list would definitely take more than
> (say) six months to design and implement?
> 
> Are there other things you would like to see on this list?
> 
> (Even among items that everyone agrees are possible for 1.1, there
> will probably have to be a winnowing process eventually.  But let's
> start by getting all the ideas on the table, then see what looks
> realistic.)
> 
> All right, let's hear it!... :-)
> 
> -Karl
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
-- 
It is MDT, Inc's policy to delete mail containing unsolicited file
attachments.
Please be sure to contact the MDT staff member BEFORE sending an e-mail
with
any file attachments; they will be able to arrange for the files to be
received.

This email, and any files transmitted with it, is confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error, please advise
postmaster@mdtsoft.com
<ma...@mdtsoft.com>.

Philip W. Dalrymple III <pw...@mdtsoft.com>
MDT Software - The Change Management Company
+1 678 297 1001
Fax +1 678 297 1003


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by Branko Čibej <br...@xbc.nu>.

Mark Benedetto King wrote:

>On Thu, Apr 01, 2004 at 11:52:00PM +0200, Branko ??ibej wrote:
>  
>
>>The trouble with inheritable properties is that I can't think of an
>>efficient way to implement them without fiddling with the FS schema. Not
>>saying ideas wouldn't be welcome, of course. Personally, though, they're
>>not high on my list for 1.1.
>>
>>    
>>
>
>Since paths are looked-up one segment at a time, couldn't we just
>keep a rolling inherited-properties context?
>  
>
Obviously. :-)

What I'm trying to say is that there are edge cases in both ACL and
inherited prop semantics -- this being one -- that you /might/ want to
solve differently for each. I'd be very happy if both turned out to use
the same mechanism, but at this point I'm not convinced that they can,
that's all.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: inheritable stuff (was: Roadmap for 1.1)

Posted by Greg Hudson <gh...@MIT.EDU>.

On Fri, 2004-04-02 at 18:02, Greg Stein wrote:
> That is true in today's system, but not in all systems. I can easily see
> using the full path as a key in a SQL-based system.

I'm having trouble imagining how this could work, while still
maintaining O(1) copies and a small size per revision.

But I think you're right.  Dynamic inheritance can have confusing
results in the presence of directory copies.  Inheriting starting values
based on the parent is consistent with what filesystems generally
provide (AFS as well as NTFS, assuming you're right about NTFS), and it
hurts less.

(How we handle the versioned-metadata-affecting-past-versions issue, I
really don't know.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

inheritable stuff (was: Roadmap for 1.1)

Posted by Greg Stein <gs...@lyra.org>.

On Thu, Apr 01, 2004 at 10:03:15PM -0500, Mark Benedetto King wrote:
> On Thu, Apr 01, 2004 at 11:52:00PM +0200, Branko ??ibej wrote:
> > 
> > The trouble with inheritable properties is that I can't think of an
> > efficient way to implement them without fiddling with the FS schema. Not
> > saying ideas wouldn't be welcome, of course. Personally, though, they're
> > not high on my list for 1.1.
> > 
> 
> Since paths are looked-up one segment at a time, couldn't we just
> keep a rolling inherited-properties context?

That is true in today's system, but not in all systems. I can easily see
using the full path as a key in a SQL-based system. In systems like this,
inherited properties and ACLs become a *real* bitch.

Also, if you "zoom in" to a specific node (say, via a copy reference),
then you are skipping the whole parent path processing. You'd have to then
try to figure out which path was used, break that down into segments, and
do the lookups.

It's for reasons like this why NTFS does not have inherited ACLs, but it
*does* default the values based on the parent. A "tear off copy", if you
will.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by Mark Benedetto King <mb...@lowlatency.com>.

On Thu, Apr 01, 2004 at 11:52:00PM +0200, Branko ??ibej wrote:
> 
> The trouble with inheritable properties is that I can't think of an
> efficient way to implement them without fiddling with the FS schema. Not
> saying ideas wouldn't be welcome, of course. Personally, though, they're
> not high on my list for 1.1.
> 

Since paths are looked-up one segment at a time, couldn't we just
keep a rolling inherited-properties context?

--ben


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by Branko Čibej <br...@xbc.nu>.

John Peacock wrote:

> Branko Čibej wrote:
>
>> IMHO one of the big mistakes we're making now is that we allow changes
>> to revprops without an audit trail, i.e., it's impossible to tell
>> _from_the_repository_ when ta revprop was changed, who changed it, and
>> what the previous value was. That's a naughty thing for a version
>> control system to do.
>
>
> That's a new table in the schema, isn't it. ;~)

So? Who says we can't add a new table in 1.x?


-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by John Peacock <jp...@rowman.com>.

Branko Čibej wrote:
> IMHO one of the big mistakes we're making now is that we allow changes
> to revprops without an audit trail, i.e., it's impossible to tell
> _from_the_repository_ when ta revprop was changed, who changed it, and
> what the previous value was. That's a naughty thing for a version
> control system to do.

That's a new table in the schema, isn't it. ;~)

> Oh, there's another reason why ACLs can't be trivially implemented as
> properties -- it should be possible to prevent principals from even
> reading the ACL.

I didn't say that ACLs would be the same things as properties, but merely that 
they would be similar.  If you assume that ACLs are something like server-side 
properties which are never directly transmitted to client, you have just solved 
the security issue.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by Branko Čibej <br...@xbc.nu>.

John Peacock wrote:

> Branko Čibej wrote:
>
>> John Peacock wrote:
>>
>>> I would assume that the ACL work will likely be implemented as a
>>> special form of property, and deal with inheritance in the tree.
>>
>>
>>
>> I think you assume too much. That is one possible model for ACL
>> implementation, but even that would differ significantly from
>> inheritable properties in that you have to be able to modify ACLs on
>> historical revisions (e.g., lock most people out from everything older
>> than r1524 in path /foo/bar because it contains sensitive information).
>
>
> An ACL should be associated with a given node (be that directory or
> file), be versioned, and have a well-defined inheritance scheme.  In a
> basic sense, the first two correspond closely to what a property is
> currently, or am I missing some deeper meaning.  I hadn't considered
> an ACL being applied back to an earlier rev, but it still looks like
> editing an attribute of a given node in the tree.

Ah, but you want to be able to track such changes. :-)
IMHO one of the big mistakes we're making now is that we allow changes
to revprops without an audit trail, i.e., it's impossible to tell
_from_the_repository_ when ta revprop was changed, who changed it, and
what the previous value was. That's a naughty thing for a version
control system to do.

> By "dealing with inheritance" I was thinking more about whether the
> /server/ would determine the applicable ACL for a given file or
> whether the /client/ would have to walk the tree.  I would think that
> obviously the former would be preferrable from a performance (as well
> as security) standpoint.

There is no question in my mind that the server has to do all the ACL
processing and authorization checks. And security is more important than
performance in this case.

>   Once a general mechanism exists for the server to report derived
> attributes (based on information in the tree not associated with the
> specific file/dir), extending that to work for both ACL's and other
> inherited attributes should be much easier.

Oh, there's another reason why ACLs can't be trivially implemented as
properties -- it should be possible to prevent principals from even
reading the ACL.

Hm. Actually we'll need access control on properties, too. What fun.

Oh yes, and properties belong to nodes, not paths; the same node can be
visible by different paths and inherit different ACLs. What fun indeed! :-)

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by John Peacock <jp...@rowman.com>.

Branko Čibej wrote:

> John Peacock wrote:
>>I would assume that the ACL work will likely be implemented as a
>>special form of property, and deal with inheritance in the tree.
> 
> 
> I think you assume too much. That is one possible model for ACL
> implementation, but even that would differ significantly from
> inheritable properties in that you have to be able to modify ACLs on
> historical revisions (e.g., lock most people out from everything older
> than r1524 in path /foo/bar because it contains sensitive information).

An ACL should be associated with a given node (be that directory or file), be 
versioned, and have a well-defined inheritance scheme.  In a basic sense, the 
first two correspond closely to what a property is currently, or am I missing 
some deeper meaning.  I hadn't considered an ACL being applied back to an 
earlier rev, but it still looks like editing an attribute of a given node in the 
tree.

By "dealing with inheritance" I was thinking more about whether the /server/ 
would determine the applicable ACL for a given file or whether the /client/ 
would have to walk the tree.  I would think that obviously the former would be 
preferrable from a performance (as well as security) standpoint.  Once a general 
mechanism exists for the server to report derived attributes (based on 
information in the tree not associated with the specific file/dir), extending 
that to work for both ACL's and other inherited attributes should be much easier.

> The trouble with inheritable properties is that I can't think of an
> efficient way to implement them without fiddling with the FS schema. Not
> saying ideas wouldn't be welcome, of course. Personally, though, they're
> not high on my list for 1.1.

I'm not saying the inheritable properties are that important for 1.1, but if the 
ACL stuff goes well, it will hopefully pave the way for other extensions, as 
long as the exact scheme to do ACL's is done in a generic fashion.  I don't have 
any knowledge of the FS schema (at this point).  I'm just waving my arms...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by Branko Čibej <br...@xbc.nu>.

John Peacock wrote:

> kfogel@collab.net wrote:
>
>>     * In-repos ACLs (may be intertwined with reserved checkouts work)
>
>
> I would assume that the ACL work will likely be implemented as a
> special form of property, and deal with inheritance in the tree.

I think you assume too much. That is one possible model for ACL
implementation, but even that would differ significantly from
inheritable properties in that you have to be able to modify ACLs on
historical revisions (e.g., lock most people out from everything older
than r1524 in path /foo/bar because it contains sensitive information).

> If so, I would like to see the existing properties become optionally
> inheritable as well.  It would also be nice if this would lead to the
> creation of custom properties at the repository level (possibly by an
> inherited property associated with the root of the repository).

The trouble with inheritable properties is that I can't think of an
efficient way to implement them without fiddling with the FS schema. Not
saying ideas wouldn't be welcome, of course. Personally, though, they're
not high on my list for 1.1.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Roadmap for 1.1

Posted by John Peacock <jp...@rowman.com>.

kfogel@collab.net wrote:

>     * In-repos ACLs (may be intertwined with reserved checkouts work)

I would assume that the ACL work will likely be implemented as a special form of 
property, and deal with inheritance in the tree.  If so, I would like to see the 
existing properties become optionally inheritable as well.  It would also be 
nice if this would lead to the creation of custom properties at the repository 
level (possibly by an inherited property associated with the root of the 
repository).

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Roadmap for 1.1

Posted by kf...@collab.net.

Hmmm.  You know what?  Let's just have the roadmap discussion here.

I've removed the "[placeholder]" bit from the Subject line, but left
other threading metadata intact.

Originally, I had wanted to come back to the list with a beautiful,
shiny, detailed proposal with lots of justifications and subpoints and
whatnot.  But the responses so far show that many people *already*
have ideas for 1.1.  Therefore, it's probably better to figure out the
roadmap iteratively on this list (Greg Stein suggested the same in a
private mail).  Sure, it may take longer, but everyone will have a
stake in the final result.

Here's what we've got so far.  If I left anything out, it's only by
accident, please follow up with the missing item.  I haven't attached
the names of the suggesters, since it's the suggestions themselves
we're interested in:

    * l10n (also known as i18n or "that gettext thang")
    * Locking (reserved checkouts)
    * Issue 1093 and friends (diff-follows-copy-history, etc)
    * Straighten out Java bindings
    * Improved release procedures & scripts
    * Full DeltaV compliance (called "pie in the sky" :-) )
    * In-repos ACLs (may be intertwined with reserved checkouts work)
    * True rename support, at least in the repository
    * symlink support
    * "What about plug-in client-side diffs?"
    * Fix N specific bugs (many in issue tracker are already marked as
        "1.1", though that set is not written in stone of course)

Let's not get down to actual voting or anything like that at this
point.  And, let's not talk about dates just yet.  Rather, let's start
with some questions:

Does anyone see anything on this list that looks hard or impossible,
given our API guidelines, for a 1.1 release?

Do we think anything on this list would definitely take more than
(say) six months to design and implement?

Are there other things you would like to see on this list?

(Even among items that everyone agrees are possible for 1.1, there
will probably have to be a winnowing process eventually.  But let's
start by getting all the ideas on the table, then see what looks
realistic.)

All right, let's hear it!... :-)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org