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
technical bits
+ 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.
)! :-)
-Karl
- Original Message
From: Mark Mielke m...@mark.mielke.cc
To: Karl Fogel kfo...@red-bean.com
Cc: Hyrum K. Wright hyrum_wri...@mail.utexas.edu; Mark Phippard
markp...@gmail.com; Subversion Dev dev@subversion.apache.org
Sent: Sun, January 17, 2010 10:31:47 AM
Subject: Re: Subversion
, 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
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
.
- Original Message
From: Mark Mielke m...@mark.mielke.cc
To: Karl Fogel kfo...@red-bean.com
Cc: Hyrum K. Wright hyrum_wri...@mail.utexas.edu; Mark Phippard
markp...@gmail.com; Subversion Dev dev@subversion.apache.org
Sent: Sun, January 17, 2010 10:31:47 AM
Subject: Re: Subversion
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
On Fri, Jan 1, 2010 at 7:22 PM, Hyrum K. Wright
hyrum_wri...@mail.utexas.edu 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
Stefan Sperling s...@elego.de:
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
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 see
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
On Fri, Jan 1, 2010 at 1:22 PM, Hyrum K. Wright
hyrum_wri...@mail.utexas.edu 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
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 read this one more closely. Are we seriously considering adding
obliterate
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 people
On Jan 14, 2010, at 11:54 AM, Mark Phippard wrote:
On Thu, Jan 14, 2010 at 11:49 AM, Hyrum K. Wright
hyrum_wri...@mail.utexas.edu 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
out our web presence on s.a.o.
* Profit! (well, maybe not...)
Each of these probably deserves it's own thread for more in-depth discussion,
but it's useful to have a high-level view. What are your plans for
Subversion in 2010?
As brought up in the other replies, I think the stated goal
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
* Build our developer community
* Finish joining the ASF
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
Warning: Paul Querna is a svn heretic.
- Original Message
From: Paul Querna p...@querna.org
To: Hyrum K. Wright hyrum_wri...@mail.utexas.edu
Cc: Subversion Dev dev@subversion.apache.org
Sent: Fri, January 8, 2010 3:31:51 PM
Subject: Re: Subversion in 2010
On Fri, Jan 1, 2010
On Fri, Jan 8, 2010 at 12:54 PM, Greg Hudson ghud...@mit.edu 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
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 the working copy is a different
On Thu, Jan 7, 2010 at 10:21 AM, Mark Mielke m...@mark.mielke.cc 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
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
that
kmra...@rockwellcollins.com wrote:
Julian Foad julianf...@btopenworld.com 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
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
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 is
[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
because
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 stored in
On Tue, Jan 5, 2010 at 5:16 PM, C. Michael Pilato cmpil...@collab.net 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
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 of
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
On Fri, Jan 1, 2010 at 1:22 PM, Hyrum K. Wright
hyrum_wri...@mail.utexas.edu 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
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
On Mon, Jan 04, 2010 at 01:17:51PM -0500, Mark Phippard wrote:
On Mon, Jan 4, 2010 at 1:01 PM, Mark Mielke m...@mark.mielke.cc 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
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 done so
On Mon, Jan 4, 2010 at 5:27 PM, Karl Fogel kfo...@red-bean.com 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)
On Mon, January 04, 2010 at 5:59 PM, Mark Phippard
mailto:markp...@gmail.com 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 to be the
36 matches
Mail list logo
