Re: Subversion in 2010 and Beyond

Stephen P Rufle wrote: > + 2^64 :) > > > Obliterate > > A new feature that cleanly removes obsolete files and other data from > > Subversion repositories. Obliterate will include comprehensive audit > > and recovery capabilities to guarantee that history is always > > available. I'm not quit

Re: Subversion in 2010 and Beyond

+ 2^64 :) > Obliterate > A new feature that cleanly removes obsolete files and other data from > Subversion repositories. Obliterate will include comprehensive audit > and recovery capabilities to guarantee that history is always > available.

Re: Subversion in 2010 and Beyond

FYI, that "Subversion in 2010 and Beyond" was a Webinar talking about some of the things coming up in Subversion 1.7 and beyond. It was produced by my employer WANdisco who also sent this summary and link to it. We broadcast it live on Tuesday this week, the four of us doing our tech

Re: Subversion in 2010

- Original Message > From: Joe Schaefer > To: C. Michael Pilato > Cc: Karl Fogel ; Mark Mielke ; > Hyrum K. Wright ; Mark Phippard > ; Subversion Dev > Sent: Mon, January 18, 2010 3:51:48 PM > Subject: Re: Subversion in 2010 > > - Original Message -

Re: Subversion in 2010

- Original Message > From: C. Michael Pilato > To: Joe Schaefer > Cc: Karl Fogel ; Mark Mielke ; > Hyrum K. Wright ; Mark Phippard > ; Subversion Dev > Sent: Mon, January 18, 2010 3:41:19 PM > Subject: Re: Subversion in 2010 > > For the sake of thos

Re: Subversion in 2010

>> Cc: Mark Mielke ; Hyrum K. Wright >> ; Mark Phippard ; >> Subversion Dev >> Sent: Mon, January 18, 2010 10:01:25 AM >> Subject: Re: Subversion in 2010 >> >> Joe Schaefer writes: >>> What I would like to see from this project is less arguing >

Re: Subversion in 2010

- Original Message > From: Karl Fogel > To: Joe Schaefer > Cc: Mark Mielke ; Hyrum K. Wright > ; Mark Phippard ; > Subversion Dev > Sent: Mon, January 18, 2010 10:01:25 AM > Subject: Re: Subversion in 2010 > > Joe Schaefer writes: > >What I would

Re: Subversion in 2010

iting code (sadly)! :-) -Karl >- Original Message >> From: Mark Mielke >> To: Karl Fogel >> Cc: Hyrum K. Wright ; Mark Phippard >> ; Subversion Dev >> Sent: Sun, January 17, 2010 10:31:47 AM >> Subject: Re: Subversion in 2010 >> >> On 01/17/2010 0

Re: Subversion in 2010

On Fri, Jan 1, 2010 at 7:22 PM, Hyrum K. Wright wrote: > I hope the holidays have been good for everybody in the Subversion community. >  In between spending some quality time with family, and eating more than I > ought, I've done a bit thinking about Subversion in 2010, what I&#x

Re: Subversion in 2010

- Original Message > From: Mark Mielke > To: Joe Schaefer > Cc: Karl Fogel ; Hyrum K. Wright > ; Mark Phippard ; > Subversion Dev > Sent: Sun, January 17, 2010 12:59:24 PM > Subject: Re: Subversion in 2010 > > > > > > > Karl said th

Re: Subversion in 2010

I consider a revision control system which ships without support for merging across renames to be "shipping software with premature design elements." I'm not in the habit of passing judgement on a project's release decisions unless I'm voting on the release. Supporting renames in merges

Re: Subversion in 2010

Karl said that "more bugs = more users = probably good". I challenged this. If you think I am wrong for challenging this, state your case. Another point on this I forgot to mention: With every conclusion, there should be some behaviour to model. That is, if we conclude that more bugs equate

Re: Subversion in 2010

- Original Message > From: Mark Mielke > To: Joe Schaefer > Cc: Karl Fogel ; Hyrum K. Wright > ; Mark Phippard ; > Subversion Dev > Sent: Sun, January 17, 2010 12:32:32 PM > Subject: Re: Subversion in 2010 > > > > > I didn't see anybody ot

Re: Subversion in 2010

I didn't see anybody other than Hiram say the project needs more/better coordination, and I certainly don't believe in guilt as a motivator, so I have no idea why you keep harping on technical debt as something objective and relevant to subversion. Cunningham was referring to shipping software w

Re: Subversion in 2010

- Original Message > From: Mark Mielke > To: Joe Schaefer > Cc: Karl Fogel ; Hyrum K. Wright > ; Mark Phippard ; > Subversion Dev > Sent: Sun, January 17, 2010 12:08:29 PM > Subject: Re: Subversion in 2010 > > On 01/17/2010 11:34 AM, Joe Schaefer wrote: &

Re: Subversion in 2010

On 01/17/2010 11:34 AM, Joe Schaefer wrote: What I would like to see from this project is less arguing about irrelevant concepts and more features in the working copy, ideally to make fewer network trips for better performance or to support queued commits so sysadmins need not panic over work sto

Re: Subversion in 2010

. - Original Message > From: Mark Mielke > To: Karl Fogel > Cc: Hyrum K. Wright ; Mark Phippard > ; Subversion Dev > Sent: Sun, January 17, 2010 10:31:47 AM > Subject: Re: Subversion in 2010 > > On 01/17/2010 02:55 AM, Karl Fogel wrote: > > I'm *tot

Re: Subversion in 2010

On 01/17/2010 02:55 AM, Karl Fogel wrote: I'm *totally* trolling now, and I'll own up to it... While I actually agree with a lot of what you've written in this thread, I think this conflation of bugs with tech debt is a mistake. They're not the same thing at all. I almost wrote that in a reply,

Re: Subversion in 2010

Mark Mielke writes: >On 01/04/2010 06:46 PM, Karl Fogel wrote: >> "Hyrum K. Wright" writes: >>> Because we are a large and mature project, there is also a certain >>> amount of maintenance cost just to maintain parity with ourselves and >>> other SCM systems. Our ever-increasing list of outstand

Re: Subversion in 2010

On Fri, Jan 15, 2010 at 08:27:06PM +0100, Steinar Bang wrote: > AOL! Acronym Over Load? > On a side note, and still on the subject: is there any movement on > replacing the multiple .svn directories with a single one? Yes, that's one of the goals of wc-ng. > Another thing I would have liked to

Re: Subversion in 2010

On Jan 15, 2010, at 1:27 PM, Steinar Bang wrote: > On a side note, and still on the subject: is there any movement on > replacing the multiple .svn directories with a single one? One of the greatest performance benefits of the current wc-ng development effort will come from such a migration. w

Re: Subversion in 2010

> Stefan Sperling : > hg patch queues also work well for this. Thanx for the heads up on both git-svn and hg patch queues. Both will certainly be better supported in development tools, than any home grown utility I could cook up. However... > But I'd also like to have this feature built int

Re: Subversion in 2010

On Thu, Jan 14, 2010 at 14:47, Hyrum K. Wright wrote: > On Jan 14, 2010, at 11:54 AM, Mark Phippard wrote: >... >> I agree we need to get more people involved.  I keep wanting to tell >> Paul and Mike to devote more time specifically to WC-NG.  It feels >> like there is a lack of public direction

Re: Subversion in 2010

On Jan 14, 2010, at 11:54 AM, Mark Phippard wrote: > On Thu, Jan 14, 2010 at 11:49 AM, Hyrum K. Wright > wrote: >> >> On Jan 14, 2010, at 9:45 AM, Mark Phippard wrote: >> >>> >>> With the pace of wc-ng slowed to a crawl it seems like we are going to >>> have a hard time even getting that feat

Re: Subversion in 2010

On Thu, Jan 14, 2010 at 11:49 AM, Hyrum K. Wright wrote: > > On Jan 14, 2010, at 9:45 AM, Mark Phippard wrote: > >> >> With the pace of wc-ng slowed to a crawl it seems like we are going to >> have a hard time even getting that feature to the point of a release. >> Why would we want to even consid

Re: Subversion in 2010

On Jan 14, 2010, at 9:45 AM, Mark Phippard wrote: > > With the pace of wc-ng slowed to a crawl it seems like we are going to > have a hard time even getting that feature to the point of a release. > Why would we want to even consider stuffing another feature into the > mix? > > We cannot stop p

Re: Subversion in 2010

some quality time with family, and eating more than I >> > ought, I've done a >> > bit thinking about Subversion in 2010, what I'd like to see happen, and >> > some goals that we >> > can work toward as a community.  Here's my list (in no particul

Re: Subversion in 2010

27;ve done a > > bit thinking about Subversion in 2010, what I'd like to see happen, and > > some goals that we > > can work toward as a community. Here's my list (in no particular order): > > > > * Release 1.7 with wc-ng and obliterate support > > Just

Re: Subversion in 2010

On Fri, Jan 1, 2010 at 1:22 PM, Hyrum K. Wright wrote: > I hope the holidays have been good for everybody in the Subversion community. >  In > between spending some quality time with family, and eating more than I ought, > I've done a > bit thinking about Subversion in 20

Re: Subversion in 2010

On Sun, Jan 10, 2010 at 03:21:17PM -0500, Greg Hudson wrote: > On Sun, 2010-01-10 at 14:13 -0500, Steinar Bang wrote: > > And then later, when I'm online, I do a an update against the > > repository, with virgin versions of the changed files, and then I copy > > in the copied-aside files, and do my

Re: Subversion in 2010

On Sun, 2010-01-10 at 14:13 -0500, Steinar Bang wrote: > And then later, when I'm online, I do a an update against the > repository, with virgin versions of the changed files, and then I copy > in the copied-aside files, and do my checkins in stages. FWIW, a lot of people seem to use git as a Subv

Re: Subversion in 2010

> Mark Phippard : > On Mon, Jan 4, 2010 at 5:27 PM, Karl Fogel wrote: >> So maybe a way to approach this is to ask: >> >> For those for whom Subversion is currently the best solution, what >> *else* do they need it to do? > From users I have heard from the two main themes would be: > 1) Pe

Re: Subversion in 2010

Greg Hudson wrote: > On Fri, 2010-01-08 at 15:31 -0500, Paul Querna wrote: > >> "Profile everything, be faster at everything" >> > > There are smart people who will disagree with me on this, but I'm not > sure the best tool for improving Subversion performance is a profiler. > Historically

Re: Subversion in 2010

On Fri, Jan 8, 2010 at 12:54 PM, Greg Hudson wrote: > On Fri, 2010-01-08 at 15:31 -0500, Paul Querna wrote: >> "Profile everything, be faster at everything" > > There are smart people who will disagree with me on this, but I'm not > sure the best tool for improving Subversion performance is a prof

Re: Subversion in 2010

Warning: Paul Querna is a svn heretic. - Original Message > From: Paul Querna > To: Hyrum K. Wright > Cc: Subversion Dev > Sent: Fri, January 8, 2010 3:31:51 PM > Subject: Re: Subversion in 2010 > > On Fri, Jan 1, 2010 at 10:22 AM, Hyrum K. Wright > wrote:

Re: Subversion in 2010

On Fri, 2010-01-08 at 15:31 -0500, Paul Querna wrote: > "Profile everything, be faster at everything" There are smart people who will disagree with me on this, but I'm not sure the best tool for improving Subversion performance is a profiler. Historically a lot of our performance issues have come

Re: Subversion in 2010

I ought, I've done a bit thinking about Subversion in 2010, what >> I'd like to see happen, and some goals that we can work toward as a >> community. Here's my list (in no particular order): >> >> * Release 1.7 with wc-ng and obliterate support >> &

Re: Subversion in 2010

On Fri, Jan 1, 2010 at 10:22 AM, Hyrum K. Wright wrote: > I hope the holidays have been good for everybody in the Subversion community. >  In between spending some quality time with family, and eating more than I > ought, I've done a bit thinking about Subversion in 2010, wh

Re: Subversion in 2010

On Thu, Jan 7, 2010 at 10:21 AM, Mark Mielke wrote: > On 01/07/2010 04:42 AM, Branko Čibej wrote: >> >> (You can get the same effect by creating a branch for each developer in >> Subversion. You can imagine the horror that integration then becomes.) >> > > It's only a horror because Subversion me

Re: Subversion in 2010

Mark Mielke wrote: > On 01/07/2010 02:11 PM, Branko Čibej wrote: >> Mark Mielke wrote: >> >>> On 01/07/2010 04:42 AM, Branko Čibej wrote: >>> Mark Mielke wrote: > The model is a bit easier to implement in ClearCase and GIT, since > these are both effectively th

Re: Subversion in 2010

On 01/07/2010 02:11 PM, Branko Čibej wrote: Mark Mielke wrote: On 01/07/2010 04:42 AM, Branko Čibej wrote: Mark Mielke wrote: The model is a bit easier to implement in ClearCase and GIT, since these are both effectively the working copy is a different stream from the parent

Re: Subversion in 2010

Mark Mielke wrote: > On 01/07/2010 04:42 AM, Branko Čibej wrote: >> Mark Mielke wrote: >> >>> The model is a bit easier to implement in ClearCase and GIT, since >>> these are both effectively the working copy is a different stream from >>> the parent whereas Subversion designer work flows tend t

Re: Subversion in 2010

On 01/07/2010 04:42 AM, Branko Čibej wrote: Mark Mielke wrote: The model is a bit easier to implement in ClearCase and GIT, since these are both effectively the working copy is a different stream from the parent whereas Subversion designer work flows tend to work directly on "trunk".

Re: Subversion in 2010

Mark Mielke wrote: > The model is a bit easier to implement in ClearCase and GIT, since > these are both effectively the working copy is a different stream from > the parent whereas Subversion designer work flows tend to work > directly on "trunk". In both ClearCase and GIT (and more so in ClearCa

Re: Subversion in 2010

On 01/06/2010 11:04 PM, Greg Hudson wrote: On Wed, 2010-01-06 at 21:26 -0500, Mark Mielke wrote: There is a race between the pull and push whereby somebody who pushes before I pull will cause my push to fail, but we generally consider this a good thing as it allows us to analyze the change a

Re: Subversion in 2010

On Wed, 2010-01-06 at 21:26 -0500, Mark Mielke wrote: > There is a race between the pull > and push whereby somebody who pushes before I pull will cause my push to > fail, but we generally consider this a good thing as it allows us to > analyze the change and determine whether additional testing

Re: Subversion in 2010

On 01/06/2010 12:12 PM, Greg Hudson wrote: On Wed, 2010-01-06 at 11:16 -0500, Julian Foad wrote: * No commitment to mixed-revision working copies. That sounds interesting, but I haven't got to grips with what it really means in terms of user work flows, and in what senses it is a

Re: Subversion in 2010

kmra...@rockwellcollins.com wrote: > Julian Foad wrote on 01/06/2010 10:16:55 AM: > > > Greg Hudson wrote: > > > On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote: > > > > "To be a compelling replacement for git/Mercurial", perhaps? > > > > > > That seems tough. > > > > Heh. A vision

Re: Subversion in 2010

On Wed, 2010-01-06 at 11:16 -0500, Julian Foad wrote: > > * No commitment to mixed-revision working copies. > > That sounds interesting, but I haven't got to grips with what it really > means in terms of user work flows, and in what senses it is an important > functional restriction versus an ad

Re: Subversion in 2010

Julian Foad wrote on 01/06/2010 10:16:55 AM: > Greg Hudson wrote: > > On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote: > > > "To be a compelling replacement for git/Mercurial", perhaps? > > > > That seems tough. > > Heh. A vision that's simple to attain is hardly a vision. I person

Re: Subversion in 2010

[Julian Foad] > > * No commitment to mixed-revision working copies. > > That sounds interesting, but I haven't got to grips with what it > really means in terms of user work flows, and in what senses it is an > important functional restriction versus an advantage. That's one of those features

Re: Subversion in 2010

Greg Hudson wrote: > On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote: > > "To be a compelling replacement for git/Mercurial", perhaps? > > That seems tough. Heh. A vision that's simple to attain is hardly a vision. What we can usefully do is identify popular features of git/Mercurial

Re: Subversion in 2010

On Tue, Jan 5, 2010 at 5:16 PM, C. Michael Pilato wrote: > Stefan Sperling wrote: >> This could be a nice way to break the copy-to problem down into smaller >> pieces, since it would allow us to implement copy-to information >> for renames in the client<->server interface before actually storing >

Re: Subversion in 2010

Stefan Sperling wrote: > This could be a nice way to break the copy-to problem down into smaller > pieces, since it would allow us to implement copy-to information > for renames in the client<->server interface before actually storing > it in the repository. copy-to information is effectively stor

Re: Subversion in 2010

On Tue, Jan 05, 2010 at 02:18:25PM -0600, Peter Samuelson wrote: > > [Stefan Sperling] > > Subversion needs to amend its data model to provide copy-to > > information, to complement the current copy-from information. > [...] > > This is easier said than done. It implies repository format changes.

Re: Subversion in 2010

[Stefan Sperling] > Subversion needs to amend its data model to provide copy-to > information, to complement the current copy-from information. [...] > This is easier said than done. It implies repository format changes. > We'd need to a way to modify old revisions to store this information > beca

Re: Subversion in 2010

On Tue, Jan 05, 2010 at 01:02:07AM -0500, Mark Mielke wrote: > On 01/04/2010 02:32 PM, Stefan Sperling wrote: > >On Mon, Jan 04, 2010 at 01:45:07PM -0500, Mark Mielke wrote: > >> > >>If it doesn't resolve them (any? all?) yet, then this would explain > >>one of the results I saw and couldn't explai

Re: Subversion in 2010

On 01/04/2010 02:32 PM, Stefan Sperling wrote: On Mon, Jan 04, 2010 at 01:45:07PM -0500, Mark Mielke wrote: If it doesn't resolve them (any? all?) yet, then this would explain one of the results I saw and couldn't explain. It knew the files had moved, it said it completed the merge - but th

RE: Subversion in 2010

On Mon, January 04, 2010 at 5:59 PM, Mark Phippard wrote: > From users I have heard from the two main themes would be: > > 1) Performance > > 2) Handling of move/renames > > Of course there are always other issues like server-based > configuration etc. but these seem t

Re: Subversion in 2010

Mark Mielke writes: >I think this is only true in the sense that more users have a better >chance of exposing existing problems. (Assuming the 'bugs' are actual >bugs' and not feature requests) > >More bugs means more technical debt, which means less efficiency for >the entire project over time. A

Re: Subversion in 2010

On 01/04/2010 06:46 PM, Karl Fogel wrote: "Hyrum K. Wright" writes: Because we are a large and mature project, there is also a certain amount of maintenance cost just to maintain parity with ourselves and other SCM systems. Our ever-increasing list of outstanding issues witnesses to the fa

Re: Subversion in 2010

On 01/04/2010 05:59 PM, Mark Phippard wrote: It is probably worth noting that Git, and probably all of the DVCS options, are particularly strong in these two areas. I suspect if we could make significant improvements in these areas we would remove the desire of a lot of people to migrate away fr

Re: Subversion in 2010

"Hyrum K. Wright" writes: >Because we are a large and mature project, there is also a certain >amount of maintenance cost just to maintain parity with ourselves and >other SCM systems. Our ever-increasing list of outstanding issues >witnesses to the fact that we aren't very good at maintaining th

Re: Subversion in 2010

On Jan 4, 2010, at 4:59 PM, Mark Phippard wrote: > On Mon, Jan 4, 2010 at 5:27 PM, Karl Fogel wrote: > >> So maybe a way to approach this is to ask: >> >> For those for whom Subversion is currently the best solution, what >> *else* do they need it to do? > > From users I have heard from the t

Re: Subversion in 2010

On Mon, Jan 4, 2010 at 5:27 PM, Karl Fogel wrote: > So maybe a way to approach this is to ask: > > For those for whom Subversion is currently the best solution, what > *else* do they need it to do? >From users I have heard from the two main themes would be: 1) Performance 2) Handling of move/r

Re: Subversion in 2010

n good for everybody in the Subversion >> community. In between spending some quality time with family, and eating >> more than I ought, I've done a bit thinking about Subversion in 2010, >> what I'd like to see happen, and some goals that we can work toward as a >&

Re: Subversion in 2010

On Mon, Jan 04, 2010 at 01:45:07PM -0500, Mark Mielke wrote: > On 01/04/2010 01:25 PM, Stefan Sperling wrote: > >On Mon, Jan 04, 2010 at 01:01:14PM -0500, Mark Mielke wrote: > >>Again, I appreciate the unique difficulties that the Subversion > >>architecture introduces, and I appreciate the efforts

Re: Subversion in 2010

On 01/04/2010 01:25 PM, Stefan Sperling wrote: On Mon, Jan 04, 2010 at 01:01:14PM -0500, Mark Mielke wrote: Again, I appreciate the unique difficulties that the Subversion architecture introduces, and I appreciate the efforts done so far - merge tracking in 1.5, tree conflict resolution in 1

Re: Subversion in 2010

On 01/04/2010 01:17 PM, Mark Phippard wrote: On Mon, Jan 4, 2010 at 1:01 PM, Mark Mielke wrote: We are still seeing reports that Subversion merges across branches are failing in areas where we expect them to succeed. I am encouraging our teams to move from ClearCase to Subversion, and the m

Re: Subversion in 2010

On Mon, Jan 04, 2010 at 01:17:51PM -0500, Mark Phippard wrote: > On Mon, Jan 4, 2010 at 1:01 PM, Mark Mielke wrote: > > Another related area of limitation here is the "reintegrate". This seems > > fundamentally broken to me. That the branch needs to be removed and > > re-created in order to "reint

Re: Subversion in 2010

On Mon, Jan 04, 2010 at 01:01:14PM -0500, Mark Mielke wrote: > Again, I appreciate the unique difficulties that the Subversion > architecture introduces, and I appreciate the efforts done so far - > merge tracking in 1.5, tree conflict resolution in 1.6 - but this > area still needs work. I'd be r

Re: Subversion in 2010

On Fri, Jan 1, 2010 at 1:22 PM, Hyrum K. Wright wrote: > I hope the holidays have been good for everybody in the Subversion community. >  In > between spending some quality time with family, and eating more than I ought, > I've done a > bit thinking about Subversion in 20

Re: Subversion in 2010

On Mon, Jan 4, 2010 at 1:01 PM, Mark Mielke wrote: > We are still seeing reports that Subversion merges across branches are > failing in areas where we expect them to succeed. I am encouraging our teams > to move from ClearCase to Subversion, and the merge limitations of > Subversion that can eit

Re: Subversion in 2010

I know it's been a trouble-some subject, and a lot of effort has been invested already, but - I would like to see "ensuring reliable merges across branches" remain as a priority, even if it is only a priority to address defects. Parallel development is one of the most important features of a

Re: Subversion in 2010

On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote: > "To be a compelling replacement for git/Mercurial", perhaps? That seems tough. The major architectural differences between git/Mercurial/Bazaar and Subversion are: * No commitment to mixed-revision working copies. * Full history o

Re: Subversion in 2010

; community. In between spending some quality time with family, and eating > more than I ought, I've done a bit thinking about Subversion in 2010, > what I'd like to see happen, and some goals that we can work toward as a > community. Here's my list (in no particular orde

Subversion in 2010

I hope the holidays have been good for everybody in the Subversion community. In between spending some quality time with family, and eating more than I ought, I've done a bit thinking about Subversion in 2010, what I'd like to see happen, and some goals that we can work toward as a