You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2004/03/31 19:38:38 UTC
Roadmap for 1.1 [placeholder]
On March 16th, I wrote:
> Next release is not scheduled yet, and Ben Collins-Sussman and I are
> sitting down tomorrow with a printout of the issues database, to do
> some sweeping, with the ultimate goal of making a 1.1 proposal here.
> In the spirit of Greg Stein's "no drive-by proposals", we feel we
> should do some homework before proposing a roadmap :-). We've got
> locking on the brain, but we need to get a sense of the issues already
> out there before trying to schedule.
My apologies for the delay in posting a 1.1 proposal.
The Chicago developers have been busy with some unexpected internal
work lately. We're nearing the end of it (we think), and will be back
here with that 1.1 proposal as soon as we can. "Soon" hopefully means
at most a few weeks.
Obviously, any such roadmap is a) advisory only, and b) totally open
to discussion and criticism. But I think having a rough roadmap
helped Subversion a lot during pre-1.0 development, and it's equally
important now to have a general consensus on what we want to see in
Subversion in the near/medium/far future -- with the greatest
specificity for "near", meaning 1.1. Too much focus kills a project;
too little focus kills a project; just the right amount of focus wins
big :-). Getting it just right is what we're aiming for, so we're
determined not to rush it.
(And of course, there's no rule that says only the Chicago devs can
propose roadmaps. But, we promise to make a good one :-), and it
helps a lot that we can sit N heads around a whiteboard and work
through stuff in person.)
Okay, more later, again sorry for the delay.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roadmap for 1.1 [placeholder]
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
>Justin Erenkrantz <ju...@erenkrantz.com> writes:
>
>
>
>>I think we can also get the locking-plan.txt implemented for a 1.1.
>>This is probably the 'largest' cross-cutting feature that I think we
>>should add into a 1.1. Greg's proposed libsvn_fs_fs shouldn't affect
>>everything, but locking would require changes through almost every
>>part of the code in some fashion. Perhaps now would be a good time to
>>review locking-plan.txt and see if it all still makes sense? (I
>>haven't looked at it in detail since we wrote it over 18 months
>>ago!)
>>
>>
>
>I've been looking at this document in great detail over the past week
>(sorry for not warning anyone). There are several short-comings and
>challenges, but I'm sure those can be worked out.
>
>
I have also been looking at that document. My absolutely No1
top-of-the-list for 1.x are exclusive locks and fs-level ACLs. I've come
to the concluseion that without these, Subversion remains a toy version
control system compared to the *real* competition out there (I don't
consider CVS competition :-).
I also think that locks and ACLs need similar modifications in the
existing code, so it's best if they're implemented in parallel.
--
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 [placeholder]
Posted by "C. Michael Pilato" <cm...@collab.net>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> I think we can also get the locking-plan.txt implemented for a 1.1.
> This is probably the 'largest' cross-cutting feature that I think we
> should add into a 1.1. Greg's proposed libsvn_fs_fs shouldn't affect
> everything, but locking would require changes through almost every
> part of the code in some fashion. Perhaps now would be a good time to
> review locking-plan.txt and see if it all still makes sense? (I
> haven't looked at it in detail since we wrote it over 18 months
> ago!)
I've been looking at this document in great detail over the past week
(sorry for not warning anyone). There are several short-comings and
challenges, but I'm sure those can be worked out.
---------------------------------------------------------------------
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
Re: Roadmap for 1.1 [placeholder]
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2004-03-31 at 19:52, Justin Erenkrantz wrote:
>
>
>>--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
>>
>>
>
>Hm. On the contrary, I think it may emphasize a weakness:
>
> touch foo; svn add foo; svn ci # Rev 1
> svn cp foo bar; svn mv foo baz; svn ci # Rev 2
> svn up -r1
> svn log -r2 foo
>
>With true renames, it would be possible (though it might require extra
>information to be kept in the FS for efficiency) to uniquely identify
>that <2,baz> is the right object to run that "svn log" operation on.
>With only "cp,rm" renames, <2,bar> and <2,baz> look exactly the same.
>
>
Unfortunately, we'd also have to drastically improve the WC if we want
the client to actually issue true renames to the server. That, and the
current FS schema (the branch ID generation) is a big obstacle.
--
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 [placeholder]
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-03-31 at 19:52, Justin Erenkrantz wrote:
> --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
Hm. On the contrary, I think it may emphasize a weakness:
touch foo; svn add foo; svn ci # Rev 1
svn cp foo bar; svn mv foo baz; svn ci # Rev 2
svn up -r1
svn log -r2 foo
With true renames, it would be possible (though it might require extra
information to be kept in the FS for efficiency) to uniquely identify
that <2,baz> is the right object to run that "svn log" operation on.
With only "cp,rm" renames, <2,bar> and <2,baz> look exactly the same.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roadmap for 1.1 [placeholder]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--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 [placeholder]
Posted by David Summers <da...@summersoft.fay.ar.us>.
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?
It sure would be nice if someone could figure out how to handle symlinks.
What aboue plug-in client-side diffs?
If JAVA bindings are now settling down then I'm planning on adding a
subversion-java RPM soonish.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roadmap for 1.1 [placeholder]
Posted by Ben Collins-Sussman <su...@collab.net>.
This is not an official proposal from the Chicago guys, but here's a
hint about what's floating in our heads right now.
On Wed, 2004-03-31 at 15:52, Justin Erenkrantz wrote:
> I'd like to have the Java bindings straightened out for a 1.1 release. A
> large portion of this work has already been done in trunk by myself and
> dlr, but we need to get more eyes and testing with it (both the javahl and
> SWIG/Java bindings). The current situation in trunk/ is far better than in
> the 1.0.x branch, so the amount of work that remains is probably not that
> much.
Mmmmm... java. Not important to me, but whatever floats your boat. :-)
>
> As far as i18n work, I think having a first cut at client-side translations
> is going to be feasible in a 1.1 timeframe.
Absolutely. Collabnet really wants (at a minimum) localized error
messages ASAP. Hence my enthusiasm for gettext support in 1.1. Expect
the Chicago guys to help out on this l18n stuff however we can.
> I think the server-side error
> messages are going to require serious discussion, so they may not be
> feasible for a 1.1-timeframe.
Yah, not necessarily as important. Could be 1.1, or maybe not. There's
a lot of design to work out.
> Perhaps we need to run a straw poll to see who can help
> with i18n translations? I'd see recruiting translators as the largest
> obstacle here.
That would be awesome.
>
> As I've mentioned before, I'd like to see us clarify and simplify our
> release practices and procedures.
Fantastic. /me throws confetti.
> I think we can also get the locking-plan.txt implemented for a 1.1. This
> is probably the 'largest' cross-cutting feature that I think we should add
> into a 1.1.
Yah. Out in Chicago, this is the "really big" feature we're hoping to
propose for 1.1.
About a week ago, cmpilato and I dusted off the very old locking
proposal that a bunch of us wrote up at ApacheCon 2002. We worked it
out on a whiteboard together, and Mike had a bunch of interesting
comments, optimizations, and tweaks to make.
That proposal has a lot of hand-waving going on, and our hope was to
present a *concrete* version of it to the list real soon. We've just
been too busy with internal stuff lately.
> For my pie-in-the-sky feature, I'd like to see full DeltaV-compliance for a
> 1.1. I don't know my time commitments yet, but this omission has been an
> annoyance to me so far - it certainly isn't critical though. I've heard
> we've got a Java-based DeltaV client floating around the office here. So,
> I might pick that up and see what happens (I know it doesn't work quite
> right against SVN); but certainly no promises for how involved I'd be.
Well, that's certaintly not going to be part of our 1.1 proposal, but
hey, it sounds fun enough for me to at least work on "after hours" with
you. :-)
The only other thing on our 1.1 checklist is 'make subcommands follow
copy history'. I've already started working on it, as you've seen in
other mails.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
javahl on Win32 was Re: Roadmap for 1.1 [placeholder]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, April 1, 2004 9:39 AM +0200 Patrick Mayweg <ma...@qint.de>
wrote:
> I am fine with the Java and Win32-fu. My Python is not so good. I have not
> yet tried to unterstand how the Win32 projects are build.
> What about the SWIG/java build? I have seen that it is included in the main
> buildsystem right now.
Our build generator is in Python, so you have to have a working knowledge of
Python to alter how the MSVC project files are written. If you want to learn
more about Python, now might be a good time. ;-)
Specifically, I think you are going to need to change how
build/generator/gen_win.py, gen_msvc_dsp.py, and gen_vcnet_vcproj.py work.
The gen_base.py file shouldn't need to be touched, but it might. I just don't
know for sure.
As for SWIG/Java, I think it'd have the same issues as javahl on Windows. If
someone gets one working, the other shouldn't be that hard to add. (Is it
working now? I didn't think it was.)
> The old automake build system could be yanked from the trunk right now. It
> is only used for the now Windows build, and for that we have got the
> integrated build. For the windows build we have other files. I think I may
> delete it over the weekend.
++1. -- 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 [placeholder]
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Justin,
Justin Erenkrantz wrote:
> --On Thursday, April 1, 2004 8:11 AM +0200 Patrick Mayweg
> <ma...@qint.de> wrote:
>
>> What do you think remains to be done for javahl?
>
>
> Probably getting the integrated build stuff to work with Windows for
> javahl and SWIG/Java. I don't have a foggy clue as to how Java could
> be integrated with MSVC. This'll require someone with Python, Java,
> and Win32-fu - a perhaps rare combination. ;-)
I am fine with the Java and Win32-fu. My Python is not so good. I have
not yet tried to unterstand how the Win32 projects are build.
What about the SWIG/java build? I have seen that it is included in the
main buildsystem right now.
>
> Once we ensure that Win32 people can build it as part of the 'core'
> build system, I think the next step would be to yank the old automake
> build system for javahl and force everyone to use the integrated build
> for javahl for a bit on the trunk. I'm sure there may be buglets in
> what we have, so it'll be important to test them out early and often.
The old automake build system could be yanked from the trunk right now.
It is only used for the now Windows build, and for that we have got the
integrated build. For the windows build we have other files. I think I
may delete it over the weekend.
>
> What do you think of this plan? -- justin
Thats fine with me.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roadmap for 1.1 [placeholder]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, April 1, 2004 8:11 AM +0200 Patrick Mayweg <ma...@qint.de>
wrote:
> What do you think remains to be done for javahl?
Probably getting the integrated build stuff to work with Windows for javahl
and SWIG/Java. I don't have a foggy clue as to how Java could be integrated
with MSVC. This'll require someone with Python, Java, and Win32-fu - a
perhaps rare combination. ;-)
Once we ensure that Win32 people can build it as part of the 'core' build
system, I think the next step would be to yank the old automake build system
for javahl and force everyone to use the integrated build for javahl for a bit
on the trunk. I'm sure there may be buglets in what we have, so it'll be
important to test them out early and often.
What do you think of this plan? -- 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 [placeholder]
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Justin,
Justin Erenkrantz wrote:
> --On Wednesday, March 31, 2004 1:38 PM -0600 kfogel@collab.net wrote:
>
>> My apologies for the delay in posting a 1.1 proposal.
>
>
> Here's my random thoughts for what I'd personally like to see in a 1.1:
>
> I'd like to have the Java bindings straightened out for a 1.1
> release. A large portion of this work has already been done in trunk
> by myself and dlr, but we need to get more eyes and testing with it
> (both the javahl and SWIG/Java bindings). The current situation in
> trunk/ is far better than in the 1.0.x branch, so the amount of work
> that remains is probably not that much.
What do you think remains to be done for javahl?
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Roadmap for 1.1 [placeholder]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, March 31, 2004 1:38 PM -0600 kfogel@collab.net wrote:
> My apologies for the delay in posting a 1.1 proposal.
Here's my random thoughts for what I'd personally like to see in a 1.1:
I'd like to have the Java bindings straightened out for a 1.1 release. A
large portion of this work has already been done in trunk by myself and
dlr, but we need to get more eyes and testing with it (both the javahl and
SWIG/Java bindings). The current situation in trunk/ is far better than in
the 1.0.x branch, so the amount of work that remains is probably not that
much.
As far as i18n work, I think having a first cut at client-side translations
is going to be feasible in a 1.1 timeframe. I think the server-side error
messages are going to require serious discussion, so they may not be
feasible for a 1.1-timeframe. The supporting build framework is now mostly
in place (modulo some further tweaks to catch edge cases), but we're going
to have to _() escape all of our messages, and push for translations from
the community. Perhaps we need to run a straw poll to see who can help
with i18n translations? I'd see recruiting translators as the largest
obstacle here.
As I've mentioned before, I'd like to see us clarify and simplify our
release practices and procedures. This has fallen off my radar due to the
gettext stuff this week, but I should hopefully find some time soon to
start a thread to rethink how we should conduct a release. Yet, in order
to come up with a concrete proposal, I need to do some more investigation
into what we are doing now and why. But, any new release techniques should
coincide with a 1.1 - the 1.0.x release procedures should be 'frozen.'
I think we can also get the locking-plan.txt implemented for a 1.1. This
is probably the 'largest' cross-cutting feature that I think we should add
into a 1.1. Greg's proposed libsvn_fs_fs shouldn't affect everything, but
locking would require changes through almost every part of the code in some
fashion. Perhaps now would be a good time to review locking-plan.txt and
see if it all still makes sense? (I haven't looked at it in detail since
we wrote it over 18 months ago!)
For my pie-in-the-sky feature, I'd like to see full DeltaV-compliance for a
1.1. I don't know my time commitments yet, but this omission has been an
annoyance to me so far - it certainly isn't critical though. I've heard
we've got a Java-based DeltaV client floating around the office here. So,
I might pick that up and see what happens (I know it doesn't work quite
right against SVN); but certainly no promises for how involved I'd be.
Wow, I had more to say than I thought I did. ;-) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org