On 13.4.2010 19:32, Johan Corveleyn wrote:
On Tue, Apr 13, 2010 at 12:29 PM, Julian Foad wrote:
Bolstridge, Andrew wrote:
To get new developers, I think the first thing that needs to be done
is to make entry easier. That means providing a setup ready-to-debug
for people. The initial
On Tue, Apr 13, 2010 at 12:29 PM, Julian Foad wrote:
> Bolstridge, Andrew wrote:
>> To get new developers, I think the first thing that needs to be done
>> is to make entry easier. That means providing a setup ready-to-debug
>> for people. The initial hurdle on any software project is getting set
Bolstridge, Andrew wrote:
> > ROADMAP
[...]
> > COMMUNITY
[...]
> > SUMMARY
[...]
> > So what say you?
>
> Well, I (as an outsider to the svn dev community) say great!
>
> My thoughts on this: firstly, to attract more people to the community,
> you need to go where they are. This dev mailing list
On Mon, Apr 12, 2010 at 13:14, Mike Dixon
wrote:
>...
> And so we have identified one of the problems.
>
> If you're serious about getting new people involved in development, getting
> a patch reviewed needs to be *easy*. If someone sends in a patch and it gets
> ignored (not maliciously, of cours
C. Michael Pilato wrote:
When the agenda item for voting new full committers into membership
was on the table, there were no candidates. Think about that: no
new full committers for Subversion in the past year. This is a bad
thing. We need to find a way to embrace and empower would-be
Subvers
Hyrum K. Wright wrote:
> While there has been lots of discussion about aspects of the following,
> there really hasn't been any dissent about the core vision and other
> ideas presented below. Given that, I propose that we massage this into
> a public, web-facing statement, and put it on the websi
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: donderdag 8 april 2010 22:41
> To: C. Michael Pilato
> Cc: dev@subversion.apache.org
> Subject: Re: Properties (was Re: Subversion Vision and Roadmap
> Proposal)
>
> On Thu, Apr 8, 2010
On Sat, Apr 10, 2010 at 11:38:22PM -0700, Alexey Neyman wrote:
> 2. In the same issue, there is a reference to keyword substitution
> implementation used by FreeBSD. Again, no further description as to why this
> implementation was not acceptable, etc.
There was, in this thread:
http://svn.haxx.
Hyrum,
On Saturday 10 April 2010 03:24:27 pm Hyrum K. Wright wrote:
> > Even CVS had the ability to (a) customize keyword expansion and (b)
> > provide custom log message templates. These features, as far as I
> > remember, were first
> > targeted as "pre-1.0" and are postponed ever since.
>
> We
On Sat, Apr 10, 2010 at 18:04, Alexey Neyman wrote:
>...
> I am not against standardizing most common approach. I just think it would be
> wasteful to focus on the issues that could be easily dealt with by configuring
> the repository.
>
> Here's an idea: have 'svnadmin create' populate the hooks
While there has been lots of discussion about aspects of the following,
there really hasn't been any dissent about the core vision and other ideas
presented below. Given that, I propose that we massage this into a public,
web-facing statement, and put it on the website somewhere. I can start
work
On Sat, Apr 10, 2010 at 11:04 PM, Alexey Neyman wrote:
> Yet, one the core features for a centralized VCS is postponed once again:
>
> =
> 1.8: repository-dictated configuration
> =
>
> Even CVS had the ability to (a) customize keyword expansion and (b) pr
On Saturday 10 April 2010 01:57:32 pm Vadim Chekan wrote:
> On Fri, Apr 9, 2010 at 9:37 PM, Greg Stein wrote:
> > On Sat, Apr 10, 2010 at 00:18, Alexey Neyman wrote:
> >> Have you looked at pre-commit hooks that may serve that purpose? I think
> >> svnperms.py may be what you're looking for - jus
On Fri, Apr 9, 2010 at 9:37 PM, Greg Stein wrote:
> On Sat, Apr 10, 2010 at 00:18, Alexey Neyman wrote:
>> Have you looked at pre-commit hooks that may serve that purpose? I think
>> svnperms.py may be what you're looking for - just disallow all operations
>> except additions on 'tags/*', and dis
Yes, I do use commit hooks and permissions. But it is fixing a
problem. And why should we fix a problem if it could be avoided?
The notion of a "snapshot" is clearly understood by everybody, so why
not to introduce it as a first class feature?
On Fri, Apr 9, 2010 at 9:18 PM, Alexey Neyman wrote:
On Sat, Apr 10, 2010 at 00:18, Alexey Neyman wrote:
> Have you looked at pre-commit hooks that may serve that purpose? I think
> svnperms.py may be what you're looking for - just disallow all operations
> except additions on 'tags/*', and disallow all operations on 'tags/*/*'.
I think people are
Have you looked at pre-commit hooks that may serve that purpose? I think
svnperms.py may be what you're looking for - just disallow all operations
except additions on 'tags/*', and disallow all operations on 'tags/*/*'.
Hope that helps,
Alexey.
On Friday 09 April 2010 05:56:44 pm Vadim Chekan w
On Fri, Apr 9, 2010 at 11:31 AM, B Smith-Mannschott
wrote:
> On Fri, Apr 9, 2010 at 10:13, Vadim Chekan wrote:
>> P.S. Plase, introduce true tags, no more "lets pretend this copy is a
>> tag".
>
> What's a "true" tag? What's it good for? How would it behave?
Tag is named snapshot. When I do
> The trick is to use the --stop-on-copy (to stop at branch point)
> -v (to show patsh) options of the svn log command:
>
> $ svn log --stop-on-copy -v .
>
> r3 | stsp | 2010-04-09 22:25:24 +0100 (Fri, 09 Apr 2010) | 1 line
>
On Fri, Apr 09, 2010 at 10:29:30PM +0100, Stefan Sperling wrote:
> On Fri, Apr 09, 2010 at 04:39:08PM -0400, Mark Mielke wrote:
> > Branch is similar. If I want to set to the point on trunk at which
> > branches/2.0 was branched, how do I do this?
> > In GIT, it's just "git checkout master", "git r
On Fri, Apr 09, 2010 at 04:39:08PM -0400, Mark Mielke wrote:
> In fact, I've found it a bit difficult to reliable say "what
> revision of trunk was this tag created from?" I think the
> information is in the copy-from attribute in the underlying FSFS
> commit, but the last time I tried to get acces
On 04/09/2010 02:31 PM, B Smith-Mannschott wrote:
What I still don't know is this: how would "true tags" behave, if
Subversion had them? What problems would that enable me to solve more
conveniently than I can now?
I don't know what the original poster meant - but something to consider:
DV
> On Fri, Apr 9, 2010 at 10:13, Vadim Chekan wrote:
> > P.S. Plase, introduce true tags, no more "lets pretend this copy is
> a tag".
>
> What's a "true" tag? What's it good for? How would it behave?
I'm not Vadim but...
Basically an attribute added to a path at a certain revisions. I would
On Fri, Apr 9, 2010 at 10:13, Vadim Chekan wrote:
> P.S. Plase, introduce true tags, no more "lets pretend this copy is a
> tag".
What's a "true" tag? What's it good for? How would it behave?
Subversion and the DVCs mean more or less the same thing when they say
"tag", modulo the fact that
> > P.S. Plase, introduce true tags, no more "lets pretend this copy
> is
> > a tag".
>
> I agree here - branches are great, but sometimes you want a 'snapshot'
> or a 'baseline' that doesn't require a whole new directory in the repo
> (especially as the number of branches you have increases,
> In particular, there are people who have patches for svn, and we don't
> handle them very well. In some cases, there is a high bar of
> review/change/resubmit that turns people off. In other cases, people
> are focused on whatever task they're working on, and the patches are
> left by the wayside
Alec Kloss wrote:
> On 2010-04-09 21:54, Tim Starling wrote:
> [chop]
>
>> My problem is that Subversion is so slow, in terms of network
>> round-trips, that's it's virtually unusable in our application for tasks
>> like merging and annotating. Chia-liang Kao has done an awesome job of
>>
>
Stefan Sperling wrote:
> On Fri, Apr 09, 2010 at 12:13:56AM -0400, Greg Stein wrote:
> > On Thu, Apr 8, 2010 at 22:55, Tim Starling wrote:
> > > C. Michael Pilato wrote:
> > >> We need to find a way to embrace and
> > >> empower would-be Subversion contributors.
> > >
> > > You could start by repl
> ROADMAP
> With that vision in mind, we identified a number of high-value improvements
> which Subversion should gain in coming releases. Then we took a casual pass
> at assigning some technical "plumbing" dependencies for each of these.
> Here's what we came up with, in the form "FEATURE: [DEP
> -Original Message-
> From: Vadim Chekan [mailto:kot.bege...@gmail.com]
> Sent: Friday, April 09, 2010 9:14 AM
> To: Subversion Development
> Subject: Re: Subversion Vision and Roadmap Proposal
>
> P.S. Plase, introduce true tags, no more "lets pretend this
On 2010-04-09 21:54, Tim Starling wrote:
[chop]
> My problem is that Subversion is so slow, in terms of network
> round-trips, that's it's virtually unusable in our application for tasks
> like merging and annotating. Chia-liang Kao has done an awesome job of
[chop]
I assume you're talking about h
Stefan Sperling wrote:
> On Fri, Apr 09, 2010 at 12:13:56AM -0400, Greg Stein wrote:
>
>> On Thu, Apr 8, 2010 at 22:55, Tim Starling wrote:
>>
>>> C. Michael Pilato wrote:
>>>
We need to find a way to embrace and
empower would-be Subversion contributors.
>>>
Thanks for great overview Michael,
I am playing with dvcs and "d" is not the point. Even if we will adopt
dvcs, it will be configured in centralized fashion. What attracts me
is:
1. ability to create a branch locally in <5sec (big project) and
never expose it. I could do branches even for code r
On Fri, Apr 09, 2010 at 12:13:56AM -0400, Greg Stein wrote:
> On Thu, Apr 8, 2010 at 22:55, Tim Starling wrote:
> > C. Michael Pilato wrote:
> >> We need to find a way to embrace and
> >> empower would-be Subversion contributors.
> >
> > You could start by replying to their mailing list posts. Jus
On Thu, Apr 8, 2010 at 22:55, Tim Starling wrote:
> C. Michael Pilato wrote:
>> We need to find a way to embrace and
>> empower would-be Subversion contributors.
>
> You could start by replying to their mailing list posts. Just a thought.
Well aware of that, and snarky behavior won't really endea
C. Michael Pilato wrote:
> We need to find a way to embrace and
> empower would-be Subversion contributors.
You could start by replying to their mailing list posts. Just a thought.
-- Tim Starling
On Thu, Apr 8, 2010 at 15:35, C. Michael Pilato wrote:
> Martin Hauner wrote:
>> Hi,
>>
>> On 06.04.10 00:01, Stefan Sperling wrote:
>>> On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
[..]
With svn:mergeinfo I have to update after each commit because its on
my root f
Hey -
+1!
I'm a game developer. I don't claim to have more insight that you guys do, but
reading about the Subversion vision on LWN prompted me to post to the comment,
but really I should echo that here. There is a case for centralized RCS, and I
think it becomes stronger as repositories scale
Martin Hauner wrote:
> Hi,
>
> On 06.04.10 00:01, Stefan Sperling wrote:
>> On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
>>> [..]
>>> With svn:mergeinfo I have to update after each commit because its on
>>> my root folder and always is out of date on the next commit.
>>
>> The ou
Hi,
On 06.04.10 00:01, Stefan Sperling wrote:
On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
[..]
With svn:mergeinfo I have to update after each commit because its on
my root folder and always is out of date on the next commit.
The out-of-dateness really comes from the mixed-r
A bit late perhaps, but also from me a big +1 to this vision and
roadmap proposal.
There are some minor points which can be discussed of course (as
always), but overall I think it's a very good plan. I especially
applaud the initiative itself to spend some time for this, taking a
step back, lookin
On 06.04.2010 12:18, Stefan Sperling wrote:
> On Tue, Apr 06, 2010 at 07:04:42AM +0200, Branko Čibej wrote:
>
>> On 05.04.2010 17:06, Stefan Sperling wrote:
>>
>>> An idea we're playing with to mitigate this problem is having designated
>>> properties in the svn: namespace which allow users
On Tue, Apr 06, 2010 at 10:31:56AM -0400, Bob Archer wrote:
> > On Tue, Apr 06, 2010 at 07:04:42AM +0200, Branko Čibej wrote:
> > > On 05.04.2010 17:06, Stefan Sperling wrote:
> > > > An idea we're playing with to mitigate this problem is having
> > designated
> > > > properties in the svn: namespa
> On Tue, Apr 06, 2010 at 07:04:42AM +0200, Branko Čibej wrote:
> > On 05.04.2010 17:06, Stefan Sperling wrote:
> > > An idea we're playing with to mitigate this problem is having
> designated
> > > properties in the svn: namespace which allow users to tell svn what
> their
> > > branching/merging
On Tue, Apr 06, 2010 at 07:04:42AM +0200, Branko Čibej wrote:
> On 05.04.2010 17:06, Stefan Sperling wrote:
> > An idea we're playing with to mitigate this problem is having designated
> > properties in the svn: namespace which allow users to tell svn what their
> > branching/merging strategy is.
>
On 05.04.2010 17:06, Stefan Sperling wrote:
> An idea we're playing with to mitigate this problem is having designated
> properties in the svn: namespace which allow users to tell svn what their
> branching/merging strategy is.
(Thereby making things even more flexible, complex, and error-prone.)
On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
> Hi,
>
> On 05.04.10 17:06, Stefan Sperling wrote:
> >On Mon, Apr 05, 2010 at 04:14:21PM +0200, Martin Hauner wrote:
> >[..]
> >>In case of merging (mostly cherry picking from trunk to live and
> >>next release branches, merge trackin
Hi,
On 05.04.10 17:06, Stefan Sperling wrote:
On Mon, Apr 05, 2010 at 04:14:21PM +0200, Martin Hauner wrote:
[..]
In case of merging (mostly cherry picking from trunk to live and
next release branches, merge tracking is nice BUT svn:merginfo on
the root folder kills it again. After each merge I
On Mon, Apr 05, 2010 at 04:14:21PM +0200, Martin Hauner wrote:
> Simplicity... actually I think subversion could or should be even
> simpler. It may be easy from our point of view around here but when
> I see how people use it, it still seems to be too complicated. One
> has to draw a line at some
Martin Hauner wrote:
> Performance
>
> I think subversion needs to improve on performance. I know that WC-NG
> will hopefully help here but I think it should be listed explicitly.
Agreed. We said many times over those 2 1/2 days "Performance is a feature."
We had performance in mind as we liste
On Sat, Apr 3, 2010 at 8:59 PM, Karl Fogel wrote:
> ...
Btw, I looked for an issue filed in Apache Infrastructure about getting
> the domain pointed to a box where we can install the planet software,
> but didn't see anything. Have any steps been taken on this yet, or is
> it "patches welcome"
Hi,
On 02.04.10 17:28, C. Michael Pilato wrote:
[..]
> VISION
>
> Subversion has no future as a DVCS tool. Let's just get that out there.
> [..]
> Someone wiser than I once said, "Where there is no vision, the people
> perish." So recognizing the benefits that Subversion already offers, and
"C. Michael Pilato" writes:
>projecting a bit into the future what we'd like to see Subversion become, we
>offer the following vision statement for your review:
>
> Subversion exists to be universally recognized and adopted as an
> open-source, centralized version control system characterized
53 matches
Mail list logo
