You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Miha Vitorovic <mv...@nil.si> on 2005/08/05 13:00:32 UTC
1.3 feature question
Since it's a slow day, I have a question... What new major feature did win
the vote for Subversion 1.3 ?
Cheers,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 1.3 feature question
Posted by Eric Gorr <ma...@ericgorr.net>.
Ben Collins-Sussman wrote:
> There's no voting process going on for "which feature goes into 1.3".
> Lots of people are working on new features on /trunk.
Would anyone happen to be working on xattr support?
--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ==
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 1.3 feature question
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 5, 2005, at 2:37 PM, Mark Parker wrote:
>
>
> Ben Collins-Sussman wrote:
>
>> * path-based authorization for svnserve (similar to what
>> mod_dav_svn has)
>>
>
>
> Any chance that path-based authorization will be implemented as
> repository-level ACLs, so that authorization won't have to be
> implemented in each separate server?
>
No, that's a ginormous libsvn_fs schema change, probably an svn 2.0
thing. Definitely something we want. Also a tremendous source of
debate about how to design/implement. (It's *very hard* to come up
with a design for ACLs on a versioned filesystem!)
All that our Summer of Code student is doing is factorizing the
mod_authz_svn code into libsvn_repos, so that both mod_auth_svn and
svnserve can share the logic. They'll use the same authz-policy files.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 1.3 feature question
Posted by Mark Parker <ma...@msdhub.com>.
Ben Collins-Sussman wrote:
>
> * path-based authorization for svnserve (similar to what mod_dav_svn
> has)
Any chance that path-based authorization will be implemented as
repository-level ACLs, so that authorization won't have to be
implemented in each separate server?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 1.3 feature question
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 5, 2005, at 9:01 AM, Miha Vitorovic wrote:
> Ben Collins-Sussman <su...@collab.net> wrote on 05.08.2005 15:05:43:
>
>
>> There's no voting process going on for "which feature goes into
>> 1.3". Lots of people are working on new features on /trunk. At some
>> point, we decide that /trunk has enough new features to justify a 1.3
>> release. Then we branch /trunk to /branches/1.3.x and let the branch
>> stabilize.
>>
>>
>
> Wasn't there a discussion somewhere about what to do next - true
> renames,
> merge tracking,... ? I remember reading something about that.
>
> But I like this approach, it must be cool to develop that way.
For those not on the dev@ list:
True renames are being worked on, but only in the repository API (it
involves a schema change.) Dunno when it will be done, but even when
it is, it won't be immediately obvious to users. It will take a long
while to get the rest of Subversion to start using the new API.
I'm working on getting svnserve to log accesses and high-level client
operations, as well as improving mod_dav_svn's logging.
Someone else is working on fixing the broken "svn checkout -N"
problem. He wants a UI which allows users to declare which
subdirectories they do/don't want, and then 'svn up' will honor the
stickiness.
We have a bunch of Summer of Code students working on new features:
* path-based authorization for svnserve (similar to what
mod_dav_svn has)
* new python bindings (that don't require pool arguments!)
* optional text-bases in the working copy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 1.3 feature question
Posted by Miha Vitorovic <mv...@nil.si>.
Ben Collins-Sussman <su...@collab.net> wrote on 05.08.2005 15:05:43:
> There's no voting process going on for "which feature goes into
> 1.3". Lots of people are working on new features on /trunk. At some
> point, we decide that /trunk has enough new features to justify a 1.3
> release. Then we branch /trunk to /branches/1.3.x and let the branch
> stabilize.
>
Wasn't there a discussion somewhere about what to do next - true renames,
merge tracking,... ? I remember reading something about that.
But I like this approach, it must be cool to develop that way.
Cheers,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 1.3 feature question
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 5, 2005, at 8:00 AM, Miha Vitorovic wrote:
> Since it's a slow day, I have a question... What new major feature
> did win
> the vote for Subversion 1.3 ?
>
There's no voting process going on for "which feature goes into
1.3". Lots of people are working on new features on /trunk. At some
point, we decide that /trunk has enough new features to justify a 1.3
release. Then we branch /trunk to /branches/1.3.x and let the branch
stabilize.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org