You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2007/12/01 13:41:23 UTC
Reality check [was: Re: merge tracking use cases]
Ben Collins-Sussman wrote:
> On Nov 30, 2007 6:15 PM, Karl Fogel <kf...@red-bean.com> wrote:
>
>>> Yes, this is what the plan has been for quite a while now.
>>>
>> I'm glad to hear you say this :-). But, others seem to think
>> differently, so it's important we hear from them too...
>>
>
> I'm not sure what to say, guys. So much drama in such a small period
> of time. Eesh.
>
> I know it's ridiculous (and rude) for a bunch of people who haven't
> been paying attention to merge-tracking details show up at the last
> minute and challenge a bunch of decisions that were made months ago...
>
... but I'm going to be even ruder and more ridiculous anyway. Guys ...
deferring basic functionality that everyone else (except CVS and
SourceSafe) takes for granted -- after almost two years spent working
heavily on merge tracking -- is a bit of a bore. Even more so because
there's already an efficient way of doing merges right with a Subversion
repository: it's called git-svn and works like a charm. Oh, and of
course there's svk.
Let's face it. 4 years after 1.0, and a year after our svn-2.0-focused
summit, Subversion is treading water. In the last two years, have we
added *any* feature that's more useful than the code bloat it produced?
We've not even solved the relatively simple problem of working correctly
on case-insensitive filesystems -- which just happens to include about
99% of all computers in the world, according to latest estimates. Many
version control projects that didn't even exist when svn-1.0 came out
have caught up and surpassed Subversion in terms of version control
functionality, performance and (!) reliability, while we've wasted time
with non-profit corporations and trademark protection.
I'm not going to try to analyze the reasons here, except to note that
losing sight of the ball does not help, nor does resting on laurels.
Quite frankly, if I were setting up a configuration management
infrastructure from scratch today, I'd probably not select Subversion as
the version control system; that's how far things have gone off course.
So ... we've made many wrong decisions, and I admit to making or
supporting quite a few of them. But I don't see any reason for
perpetuating them. So I suggest you (we?) all take a step back and
*seriously* start moving in the right direction; otherwise in the next
few years, Subversion and CVS will be jostling for the best position in
the dinosaur exhibit of the trash-heap of history.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check [was: Re: merge tracking use cases]
Posted by Jay Levitt <li...@shopwatch.org>.
> Quite frankly, if I were setting up a configuration management
> infrastructure from scratch today, I'd probably not select Subversion as
> the version control system; that's how far things have gone off course.
I gotta say, as a "just a user", I am unnerved by how many projects I've
seen in the past month that are moving off of Subversion. It's not even
posed as a question of "should we" - just a question of which
distributed system they should use. And this is in the Ruby/Rails
world, where svn is embedded into the infrastructure and, thus,
basically comes free.
I've seen Ben's blog post, and it made sense to me. And I'm sure that,
just as with any other "start from scratch" project, they're throwing
away five years of hard-but-necessary decisions about edge cases. Yet,
for whatever reason, nobody seems to be hitting those edge cases - or,
if they are, they just don't consider them worth writing about.
As I say - unnerving.
Jay Levitt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check [was: Re: merge tracking use cases]
Posted by Mark Phippard <ma...@gmail.com>.
On 12/1/07, Jay Levitt <li...@shopwatch.org> wrote:
> > I'm just trying to point out that Subversion
> > is trying to solve a much more complicated problem than the newer
> > systems.
>
> This may be a really dumb question:
>
> Does the complicated problem need solving?
>
> Importantly, that's a different question than "Do people use the
> features that solve the complicated problem?" I'm asking if they still
> *need* to stay solved - and whether they need to stay solved more than
> other features need to *get* solved. I've never seen subtrees and
> combined WCs in use, and in fact some popular tools (I think) don't even
> support all the variations (Mark?).
I think all of those features are definitely used regularly -- just
look at the mailing lists. If anything people are asking for more and
more of these things.
The problem is that since all of those features exist, we cannot just
say that merge tracking does not need to support them, and supporting
them takes time.
It is a good question to ask, but yes all of those features you
mentioned are used regularly by our users.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check [was: Re: merge tracking use cases]
Posted by Jay Levitt <li...@shopwatch.org>.
> I'm just trying to point out that Subversion
> is trying to solve a much more complicated problem than the newer
> systems.
This may be a really dumb question:
Does the complicated problem need solving?
Importantly, that's a different question than "Do people use the
features that solve the complicated problem?" I'm asking if they still
*need* to stay solved - and whether they need to stay solved more than
other features need to *get* solved. I've never seen subtrees and
combined WCs in use, and in fact some popular tools (I think) don't even
support all the variations (Mark?).
And I'm asking it because I've recently had the opportunity to rethink a
project I did about fifteen years ago - a mail server that had some
unique characteristics, like the ability to instantly verify recipients
and then guarantee delivery. That wasn't even considered a feature; it
was simply the way it had to work, and you wouldn't think of changing it
any more than you'd think of changing the server to work without any
CPUs installed.
But that core aspect turned out to have huge implications for design.
Other systems were doing interesting things that just Weren't That
Simple for us. The others were, as you say, solving a different
problem. Once you understood our design, you understood why things had
to be the way they were, and it made perfect sense. It almost became a
rite of passage for new hires: They'd come in with all sorts of ideas
they wanted to implement, and one by one, we'd beat them down with The
Story of why it had to be this way, and why those other ideas didn't
work here.
Fifteen years later, nobody expects e-mail to be guaranteed deliverable.
Nobody misses that it used to be that way. But everybody expects it
to do all sorts of other things that guaranteed delivery prevents - and,
therefore, nobody uses that mail system any more.
Subversion feels like it might have A Story of why it Has To Be That
Way... make sure it really does.
Jay Levitt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check [was: Re: merge tracking use cases]
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 1, 2007 12:14 PM, Branko Čibej <br...@xbc.nu> wrote:
> David Glasser wrote:
> > The hg model makes these operations essentially impossible, and thus I
> > don't see how it can extend to truly enormous, interconnected
> > codebases where an individual user only needs to work on some parts of
> > it at a time, but that part may vary enormously among users.
>
> I apologize for barging in again ... and doing another kind of off-topic ...
>
> http://www.selenic.com/mercurial/wiki/index.cgi/PartialClone
> http://www.selenic.com/mercurial/wiki/index.cgi/TrimmingHistory
Thanks for the pointers!
I do think it's telling that the PartialClone page and issue haven't
been updated by hg devs since the beginning of 2006. While I suspect
that "partial checkout" wouldn't be too hard for them to implement
(and that's the only part that the hg devs addressed on the issue),
"partial clone" is the hard part, and it looks like their thinking is
still at the stage analogous to "we can just put in a bunch of
svn:mergeinfo props and it'll all work out"...
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
Re: Reality check [was: Re: merge tracking use cases]
Posted by Branko Čibej <br...@xbc.nu>.
David Glasser wrote:
> The hg model makes these operations essentially impossible, and thus I
> don't see how it can extend to truly enormous, interconnected
> codebases where an individual user only needs to work on some parts of
> it at a time, but that part may vary enormously among users.
I apologize for barging in again ... and doing another kind of off-topic ...
http://www.selenic.com/mercurial/wiki/index.cgi/PartialClone
http://www.selenic.com/mercurial/wiki/index.cgi/TrimmingHistory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check [was: Re: merge tracking use cases]
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 1, 2007 5:41 AM, Branko Čibej <br...@xbc.nu> wrote:
> Ben Collins-Sussman wrote:
> > On Nov 30, 2007 6:15 PM, Karl Fogel <kf...@red-bean.com> wrote:
> >
> >>> Yes, this is what the plan has been for quite a while now.
> >>>
> >> I'm glad to hear you say this :-). But, others seem to think
> >> differently, so it's important we hear from them too...
> >>
> >
> > I'm not sure what to say, guys. So much drama in such a small period
> > of time. Eesh.
> >
> > I know it's ridiculous (and rude) for a bunch of people who haven't
> > been paying attention to merge-tracking details show up at the last
> > minute and challenge a bunch of decisions that were made months ago...
> >
>
> ... but I'm going to be even ruder and more ridiculous anyway. Guys ...
> deferring basic functionality that everyone else (except CVS and
> SourceSafe) takes for granted -- after almost two years spent working
> heavily on merge tracking -- is a bit of a bore. Even more so because
> there's already an efficient way of doing merges right with a Subversion
> repository: it's called git-svn and works like a charm. Oh, and of
> course there's svk.
>
> Let's face it. 4 years after 1.0, and a year after our svn-2.0-focused
> summit, Subversion is treading water. In the last two years, have we
> added *any* feature that's more useful than the code bloat it produced?
> We've not even solved the relatively simple problem of working correctly
> on case-insensitive filesystems -- which just happens to include about
> 99% of all computers in the world, according to latest estimates. Many
> version control projects that didn't even exist when svn-1.0 came out
> have caught up and surpassed Subversion in terms of version control
> functionality, performance and (!) reliability, while we've wasted time
> with non-profit corporations and trademark protection.
>
> I'm not going to try to analyze the reasons here, except to note that
> losing sight of the ball does not help, nor does resting on laurels.
> Quite frankly, if I were setting up a configuration management
> infrastructure from scratch today, I'd probably not select Subversion as
> the version control system; that's how far things have gone off course.
>
> So ... we've made many wrong decisions, and I admit to making or
> supporting quite a few of them. But I don't see any reason for
> perpetuating them. So I suggest you (we?) all take a step back and
> *seriously* start moving in the right direction; otherwise in the next
> few years, Subversion and CVS will be jostling for the best position in
> the dinosaur exhibit of the trash-heap of history.
I agree with Brane in part. After all, it's pretty easy to look at a
distributed system like hg or git and say "merge tracking is so easy
there, it barely even qualifies as a feature! why is svn so dumb?"
And in fact, if the model of hg (I'll use hg as an example because
it's the distributed system I know best) was strictly better than
Subversion's model in all ways, then continuing with the Subversion
model would clearly be silly.
So what are the differences between the Subversion and the hg model
that makes merging so easy for them and so hard for us?
The obvious answer is "they have deep history in the client; we
don't". However, I *don't* actually think that this is what makes our
merge-tracking job hard. We could keep all the history in the client
(like svk!) and tracking merges would still be hard in the general
model we try to support.
The less obvious answer is "Subversion supports operations on things
other than 'the tree'". In the hg model, a project is a tree. Every
revision is a transformation on the entire tree. A branch is just a
different transformation on the same tree. All their simplicity
derives from this fact: revisions apply cleanly against their parents
because their parent is exactly the same. Subversion on the other
hand tries to support things like "read authorization" (where some
users can't see parts of the tree), "subtree checkouts" (where you can
do versioned operations on a small part of an enormous project without
ever needing to download data about the rest of the project), and
starting in 1.5 "depth-filtered operations" (commits, updates, diffs,
etc based on an arbitrary subtree of a tree).
The hg model makes these operations essentially impossible, and thus I
don't see how it can extend to truly enormous, interconnected
codebases where an individual user only needs to work on some parts of
it at a time, but that part may vary enormously among users. While it
might certainly be feasible for every user to locally have the entire
history of the subproject they are working on, it would not be
feasible for them to have the complete history of the entire codebase.
Thus the fundamental barrier to adoption of the Mercurial model is
not "no room to download the entire time dimension" but "no room to
download the entire space dimension".
You can see this clearly in our current merge tracking implementation;
one of the major complexities is "inherited mergeinfo". This concept
doesn't exist in the mercurial model, because it is fundamentally
about dealing with the repercussions of an operation on a subtree.
And while SVK does a reasonable job of merge tracking, it doesn't
actually support the entire Subversion model: it essentially places
tickets on the roots of branches and doesn't do a great job of
tracking merges that don't go between entire branches.
I don't mean this as a defense of the current merge-tracking
design/implementation. I'm just trying to point out that Subversion
is trying to solve a much more complicated problem than the newer
systems. For many use cases (for example, moderately sized open
source projects), the hg model is satisfactory. But extending their
model to cover all of Subversion's use cases seems to me as difficult
as extending Subversion to do merging as well as they do.
(Somehow, the world needs a version control system that supports the
changeset DAG concept *and* the subtrees-matter concept at the same
time. Perhaps that's what Subversion 2.0 needs to be. Or Mercurial
2.0. But neither one gets both concepts right in 1.0.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
Re: Reality check [was: Re: merge tracking use cases]
Posted by Troy Curtis Jr <tr...@gmail.com>.
On Dec 1, 2007 7:41 AM, Branko Čibej <br...@xbc.nu> wrote:
> Ben Collins-Sussman wrote:
> > On Nov 30, 2007 6:15 PM, Karl Fogel <kf...@red-bean.com> wrote:
> >
> >>> Yes, this is what the plan has been for quite a while now.
> >>>
> >> I'm glad to hear you say this :-). But, others seem to think
> >> differently, so it's important we hear from them too...
> >>
> >
> > I'm not sure what to say, guys. So much drama in such a small period
> > of time. Eesh.
> >
> > I know it's ridiculous (and rude) for a bunch of people who haven't
> > been paying attention to merge-tracking details show up at the last
> > minute and challenge a bunch of decisions that were made months ago...
> >
>
> ... but I'm going to be even ruder and more ridiculous anyway. Guys ...
> deferring basic functionality that everyone else (except CVS and
> SourceSafe) takes for granted -- after almost two years spent working
> heavily on merge tracking -- is a bit of a bore. Even more so because
> there's already an efficient way of doing merges right with a Subversion
> repository: it's called git-svn and works like a charm. Oh, and of
> course there's svk.
>
I've been looking for somewhere to mention this! I've recently been
playing around with both svk and git. In fact I've been using git-svn
to track my recent CLI relative-url work. Looking more into this I
have discovered some things.
First off, git-svn works great for tracking your personal merges, but
it doesn't have the ability to publish them to other Subversion users
(unless they clone your git repo, and I'm not even sure that is
supported). Also, I very quickly ran into a common issue that git's
merge had a terrible time figuring out. I tested it on my subversion
trunk WC (using update for the "merge", since the git-svn rebase was
the operation I was doing in git) and the conflict was infinitely more
understandable. I think it was maybe because Subversion's merge
algorithm looks at ancestry ?? Maybe?? I'm not sure. (FYI I added a
new function at the end of a file, then rebased that change on someone
else's newly added function. Git tried very hard to interleave the
changes which made the conflict markers basically unreadable.
Subversion correctly treated them as diff "chunks" and conflicted the
whole chunks). And the diffs of the interesting files were much
easier to obtain.
Not only that, but git just completely ignores tracking
cherry-picking. By simply defining merges and cherry-picking as two
completely separate commands, git advocates (*cough* Linus) can call
other VCS like Subversion "stupid" and "idiotic" because they "forget"
about merges. I'm pretty sure if you cherry picked several commits
from a branch, then decided to just merge the whole thing that git
would have it's own problems. Maybe I have a very Subversion-ized
mindset on the merge/cherry-pick concept but I really think that
ignoring cherry-picks only solves half the problem. Though admittedly
an important half for decentralized development.
But before going the git-svn route I tried to use svk for my local
tracking, since it didn't feel so much like treason :). However, my
first pull resulted in merge conflicts in three files that I had never
touched, so I just stopped there. Of course, I didn't like the single
repository containing everything concept anyway. Not to mention the
my revision/your revision confusion (git definitely got it right there
for a DVCS) or the fact that the wc's had no admin information in tree
to distinguish it from "just some directory".
> Let's face it. 4 years after 1.0, and a year after our svn-2.0-focused
> summit, Subversion is treading water. In the last two years, have we
> added *any* feature that's more useful than the code bloat it produced?
> We've not even solved the relatively simple problem of working correctly
> on case-insensitive filesystems -- which just happens to include about
> 99% of all computers in the world, according to latest estimates. Many
> version control projects that didn't even exist when svn-1.0 came out
> have caught up and surpassed Subversion in terms of version control
> functionality, performance and (!) reliability, while we've wasted time
> with non-profit corporations and trademark protection.
>
I haven't been following the case-insensitive filesytem issues myself,
I steer clear of those inferior filesystems. :) However, I have
noticed it coming up pretty often. I'm not sure that git really runs
that great at all on Windows the last I checked, and it seems to me
that Subversion does a pretty decent job being cross-platform. But
like I said I've not used those "other" systems much.
> I'm not going to try to analyze the reasons here, except to note that
> losing sight of the ball does not help, nor does resting on laurels.
> Quite frankly, if I were setting up a configuration management
> infrastructure from scratch today, I'd probably not select Subversion as
> the version control system; that's how far things have gone off course.
>
> So ... we've made many wrong decisions, and I admit to making or
> supporting quite a few of them. But I don't see any reason for
> perpetuating them. So I suggest you (we?) all take a step back and
> *seriously* start moving in the right direction; otherwise in the next
> few years, Subversion and CVS will be jostling for the best position in
> the dinosaur exhibit of the trash-heap of history.
>
That's a great idea. So what do you propose is the "right" direction?
I'm sure the devs are open to suggestions. There is much work going
on trying to solve the merge-tracking problem (for both wholesale
merges AND cherrypicking) and I'm pretty sure I've seen various emails
about the case-insensitivity issue flying around (and it doesn't seem
like a particularly "simple" problem).
> -- Brane
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
Re: Reality check
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 18, 2007 at 07:05:27AM -0600, Ben Collins-Sussman wrote:
> On Dec 17, 2007 9:37 PM, Roy Franz <ro...@gmail.com> wrote:
>
> > I personally think that some of these basic usability issues are much
> > more important than offline operation, etc.
>
> The only reason you can answer the question "which tags contain this
> file?" so easily in CVS is because tags are based on labeling files.
> The underlying RCS file has the list of tag-labels right there, ready
> to go. The tradeoff, of course, is that creating tags becomes an O(N)
> operation -- I've seen companies sit and wait for *hours* to make a
> tag on big trees in CVS or Clearcase.
I've been doing this myself and it really sucks!
I maintain a set of changes against the FreeBSD source tree to
implement support for wake on lan. I've been doing so in a copy
of their CVS repository. They have hacked cvs to allow maintaining
local branches in a repo copied with cvsup. But maintaining my
changes on two branches (for FreeBSD 6.x and 7.x) involves much tagging
and merging which takes a long time in CVS. A single tag alone takes about
30 minutes on a tree the size of the FreeBSD source tree, even though
the repo sits on local disk! So most of the time I can spare to work
on this involves waiting for CVS.
I'm still looking for alternatives, but have not yet found a solution
that does not involve a vendor branch. I want incremental native cvs imports
instead, cvs2svn doesn't seem to support this. It seems there is no tool
that supports icremental imports and is at the same time actually able to
import a single branch from the FreeBSD CVS tree. Neither git-svnimport
nor "mtn cvs_import" manage that without crashing. I'll probably have
to look into the non-free perforce next :-/
> You might want to read this, as it directly talks about your problem:
>
> http://svn.collab.net/repos/svn/trunk/notes/schema-tradeoffs.txt
Interesting hint, I'll look into that some time.
I wonder though if there really isn't a way to get both O(1) tagging
and O(1) "file @rev" -> "tag" lookups in the current design.
With "copied-to" info in the repository (instead of only "copied-from"
info) we'd get a bit quicker at answering "file @rev" -> "tag" mappings,
but I'm not entirely sure if this is a clean solution.
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: Reality check
Posted by Ben Collins-Sussman <su...@red-bean.com>.
I'm sold. When we (whoever "we" is) sit down to redesign the whole
repository filesystem someday, I agree that we should figure out a way
to do O(1) copies *and* still have an fast reverse-index of files to
tags.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Roy Franz <ro...@gmail.com>.
On Dec 18, 2007 11:38 AM, Steven Bakke <st...@amd.com> wrote:
>
>
> On Dec 18, 2007, at 12:47 PM, Roy Franz wrote:
>
> > On Dec 18, 2007 5:05 AM, Ben Collins-Sussman <su...@red-bean.com>
> > wrote:
> >> On Dec 17, 2007 9:37 PM, Roy Franz <ro...@gmail.com> wrote:
> >>
> >>> I personally think that some of these basic usability issues are
> >>> much
> >>> more important than offline operation, etc.
> >>
> >> The only reason you can answer the question "which tags contain this
> >> file?" so easily in CVS is because tags are based on labeling files.
> >> The underlying RCS file has the list of tag-labels right there, ready
> >> to go. The tradeoff, of course, is that creating tags becomes an
> >> O(N)
> >> operation -- I've seen companies sit and wait for *hours* to make a
> >> tag on big trees in CVS or Clearcase. So the new design isn't
> >> always
> >> a "very visibile regression in usability", but is more like a game of
> >> whack-a-mole. Make one thing easier, something else gets
> >> harder. :-)
> >> Though, maybe with a careful redesign, it's possible to whack both
> >> moles at once...
> >>
> >> You might want to read this, as it directly talks about your problem:
> >>
> >> http://svn.collab.net/repos/svn/trunk/notes/schema-tradeoffs.txt
> >>
> >
> > I understand the tradeoffs and the underlying implementation, so I
> > realize that this is
> > not an easy problem to address. I guess I am a little frustrated that
> > there doesn't seem to be any interest
> > in addressing it (or even agreeing that it is a problem.) In our
>
> I'll second that. I think one issue is getting acknowledgement that
> "tags as labels" are
> a valid use-case which is only partially addressed by "tags as cheap
> copies". It
> is not really a replacement. Based upon the number of times this
> issue has come
> up in the users mailing list, there seems to be demand for this
> capability.
>
>
> > organization, a small number of people make the tags, but almost
> > everybody is interested
> > in asking the 'hard questions' (hard for SVN, easy for CVS) about
> > tags. This leads to an overall not-so-positive feeling about
> > Subversion,
> > as most people see the regressions, while only a few see the gains. I
> > am surprised that more organizations don't run into the same problem.
> > This probably isn't a 'sexy' feature (like merge tracking,
> > disconnected/distributed, etc.), but is a significant usability wart.
> >
> > Roy
>
>
>
>
I don't know if tags-as-labels implies other capabilities, but most of
what I am looking for
is for svn log to (optionally) show the tags that have been 'applied'
to a specific revision of a file.
The other interesting question is for a file/tag pair, which revisions
of the file are equivalent to the tagged version.
If I make a branch from trunk, then tag it, if file 'a' hasn't changed
on the branch then I would want the 'svn log' output
on trunk to indicate the version on trunk that is equivalent to the
tagged version. (It won't be the same path that was tagged, but will
have the same contents.)
I see this as a meta-data lookup problem, so I don't care if the
underlying revision storage is changed or not. Having this
information cached (and the cache updated after the commit) is
perfectly fine, and I think balances the O(1) commit performance.
Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Steven Bakke <st...@amd.com>.
On Dec 18, 2007, at 12:47 PM, Roy Franz wrote:
> On Dec 18, 2007 5:05 AM, Ben Collins-Sussman <su...@red-bean.com>
> wrote:
>> On Dec 17, 2007 9:37 PM, Roy Franz <ro...@gmail.com> wrote:
>>
>>> I personally think that some of these basic usability issues are
>>> much
>>> more important than offline operation, etc.
>>
>> The only reason you can answer the question "which tags contain this
>> file?" so easily in CVS is because tags are based on labeling files.
>> The underlying RCS file has the list of tag-labels right there, ready
>> to go. The tradeoff, of course, is that creating tags becomes an
>> O(N)
>> operation -- I've seen companies sit and wait for *hours* to make a
>> tag on big trees in CVS or Clearcase. So the new design isn't
>> always
>> a "very visibile regression in usability", but is more like a game of
>> whack-a-mole. Make one thing easier, something else gets
>> harder. :-)
>> Though, maybe with a careful redesign, it's possible to whack both
>> moles at once...
>>
>> You might want to read this, as it directly talks about your problem:
>>
>> http://svn.collab.net/repos/svn/trunk/notes/schema-tradeoffs.txt
>>
>
> I understand the tradeoffs and the underlying implementation, so I
> realize that this is
> not an easy problem to address. I guess I am a little frustrated that
> there doesn't seem to be any interest
> in addressing it (or even agreeing that it is a problem.) In our
I'll second that. I think one issue is getting acknowledgement that
"tags as labels" are
a valid use-case which is only partially addressed by "tags as cheap
copies". It
is not really a replacement. Based upon the number of times this
issue has come
up in the users mailing list, there seems to be demand for this
capability.
> organization, a small number of people make the tags, but almost
> everybody is interested
> in asking the 'hard questions' (hard for SVN, easy for CVS) about
> tags. This leads to an overall not-so-positive feeling about
> Subversion,
> as most people see the regressions, while only a few see the gains. I
> am surprised that more organizations don't run into the same problem.
> This probably isn't a 'sexy' feature (like merge tracking,
> disconnected/distributed, etc.), but is a significant usability wart.
>
> Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Roy Franz <ro...@gmail.com>.
On Dec 18, 2007 5:05 AM, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On Dec 17, 2007 9:37 PM, Roy Franz <ro...@gmail.com> wrote:
>
> > I personally think that some of these basic usability issues are much
> > more important than offline operation, etc.
>
> The only reason you can answer the question "which tags contain this
> file?" so easily in CVS is because tags are based on labeling files.
> The underlying RCS file has the list of tag-labels right there, ready
> to go. The tradeoff, of course, is that creating tags becomes an O(N)
> operation -- I've seen companies sit and wait for *hours* to make a
> tag on big trees in CVS or Clearcase. So the new design isn't always
> a "very visibile regression in usability", but is more like a game of
> whack-a-mole. Make one thing easier, something else gets harder. :-)
> Though, maybe with a careful redesign, it's possible to whack both
> moles at once...
>
> You might want to read this, as it directly talks about your problem:
>
> http://svn.collab.net/repos/svn/trunk/notes/schema-tradeoffs.txt
>
I understand the tradeoffs and the underlying implementation, so I
realize that this is
not an easy problem to address. I guess I am a little frustrated that
there doesn't seem to be any interest
in addressing it (or even agreeing that it is a problem.) In our
organization, a small number of people make the tags, but almost
everybody is interested
in asking the 'hard questions' (hard for SVN, easy for CVS) about
tags. This leads to an overall not-so-positive feeling about
Subversion,
as most people see the regressions, while only a few see the gains. I
am surprised that more organizations don't run into the same problem.
This probably isn't a 'sexy' feature (like merge tracking,
disconnected/distributed, etc.), but is a significant usability wart.
Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Dec 17, 2007 9:37 PM, Roy Franz <ro...@gmail.com> wrote:
> I personally think that some of these basic usability issues are much
> more important than offline operation, etc.
The only reason you can answer the question "which tags contain this
file?" so easily in CVS is because tags are based on labeling files.
The underlying RCS file has the list of tag-labels right there, ready
to go. The tradeoff, of course, is that creating tags becomes an O(N)
operation -- I've seen companies sit and wait for *hours* to make a
tag on big trees in CVS or Clearcase. So the new design isn't always
a "very visibile regression in usability", but is more like a game of
whack-a-mole. Make one thing easier, something else gets harder. :-)
Though, maybe with a careful redesign, it's possible to whack both
moles at once...
You might want to read this, as it directly talks about your problem:
http://svn.collab.net/repos/svn/trunk/notes/schema-tradeoffs.txt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> But that's not the way a mature software project runs. We need to add
> the 1.5 features on the architecture we've got, because users cannot
> be expected to wait until the New World Order.
That was indeed one of the points of my first post ... except that there
seems to be some disagreement as to what "1.5 features" really are. IMHO
it's more important to correctly support merge-back than perfect
cherry-picking; I realise it's quite late in the day for that observation.
> Let's get 1.5 out the door, with merge-tracking, before we start
> getting starry-eyed about 2.0. I'd love to be more idealistic about
> architectural changes, but that's only possible when you don't have a
> huge installed base and lots of compatibility guarantees to keep.
>
I think we should be quite pragmatic here and stick to our promises --
all \000 of them. It's somewhat obvious that there must be a hassle-free
migration path from 1.x to 2.x, and "least-surprise" compatibility in
the most commonly used parts of the UI. Anything else is icing on the
cake, to be terminated without prejudice if it limits what we can do
with architectural changes.
>> "Ceterum censeo Carthaginem esse delendam."
>>
>
> Eventually, but... "Lord, give me chastity and continence, but *not yet*."
>
I'll drink, etc., to that. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Dec 3, 2007 4:45 AM, Karl Fogel <kf...@red-bean.com> wrote:
> At the summit, we did a good job of developing a technical consensus
> about where to go. But we didn't come up with a plan of attack, a way
> to get from here to there while simultaneously maintaining the current
> Subversion. We're going to have to have that conversation after 1.5;
> but in the meantime we can still make a very useful release based on
> today's architecture.
Yes yes, we have *got* to have another summit after 1.5 is released.
We need to recapture focus, and figure how to balance 1.x maintenance
with 2.0 redesigns.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@xbc.nu> writes:
> In fact, I was hoping to provoke reactions to the tune of "let's show
> this lazy idiot who hasn't written a line of code in a month of Sundays
> what we're about!" Not a very orthodox approach in this forum, I'll
> admit -- hence the "rude and ridiculous" -- but it's the best I can do
> right now, and it did get some response in the right direction. :)
Oh, I'm sure you've been sitting around eating strawberries and cream
this whole time, yes :-).
> So for now I'll throw a few bones that I and/or others have been talking
> about for a while now:
>
> * The repository architecture (schema, semantics and back-end
> implementation) needs a complete overhaul. Refer to DannyB's and
> my and others' presentations at last year's Summit.
> * We do not have the resources to maintain two (or more!) repository
> back-ends or four (or more!) access methods.
> o Focus on /one/ repos backend -- the new one
> o Drop WebDAV as a protocol spoken by the client. We're not
> speaking real WebDAV anyway. If we need an HTTP-based access
> method (and I believe we do, for firewall/proxy reasons if
> no other), make it a RESTful variant of the svnserve
> protocol instead.
> o mod_dav_svn is useful for integration with non-Subversion
> clients (autocommit is useful) -- but it should be limited
> to that.
> * The working-copy architecture ... (shudder).
> * Divorce branches from copies. Branch, tag and copy are all
> conceptually different. Our simple "branch == copy" paradigm is
> indeed a low hurdle for people coming from SouceSafe or no VCS at
> all (wait, aren't those the same?) ... but is a total pain for
> project management. The number of hoops one has to jump through
> and "don't do that!" recommendations one has to follow to get and
> maintain a marginally sane repository structure is a serious hint.
> * Last but not least ... We should stop fiddling about with
> object-oriented code written in C. Our approach is only slightly
> better than the horror that is GObject. If we must stay with
> native-compiled libraries, let's do it in C++ ... in the last 7
> years, GCC 4 and Visual Studio 8 have arrived, so most of our
> original arguments for sticking with C no longer apply.
I think everyone agrees on these things as the long term plan. And
it's very tempting to say "Hey, why spend one minute writing any code
that's not directly leading to one of these things?"
But that's not the way a mature software project runs. We need to add
the 1.5 features on the architecture we've got, because users cannot
be expected to wait until the New World Order. The 1.5 development
process has made clear that we need some architectural improvements
(if I may indulge in understatement), but that doesn't mean we stop
developing 1.5 right now and spend months or more rewriting the
understructure.
At the summit, we did a good job of developing a technical consensus
about where to go. But we didn't come up with a plan of attack, a way
to get from here to there while simultaneously maintaining the current
Subversion. We're going to have to have that conversation after 1.5;
but in the meantime we can still make a very useful release based on
today's architecture. (FWIW, I don't think the current architecture
is holding us back quite as much as you do. It has its warts, but it
also deals with some things very well.)
Let's get 1.5 out the door, with merge-tracking, before we start
getting starry-eyed about 2.0. I'd love to be more idealistic about
architectural changes, but that's only possible when you don't have a
huge installed base and lots of compatibility guarantees to keep.
> "Ceterum censeo Carthaginem esse delendam."
Eventually, but... "Lord, give me chastity and continence, but *not yet*."
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Troy Curtis Jr <tr...@gmail.com>.
On Dec 6, 2007 3:17 AM, <ph...@bmlv.gv.at> wrote:
> Hyrum K. Wright wrote:
> > I have similar feelings. In working on some of the auditing code, I've
> > often thought "gee, if I could only tell if this copy is a branch or a
> > true copy." Having branches in directory hierarchy is very useful,
> > especially when browsing them using mod_dav_svn and my favorite web
> > browser. But the extra branch v. copy metadata would be useful.
> How about just defining some extra property, that should be set to define some
> copy as a branch? Eg. "svn:branch-from" and some source
> (repository-root-relative) path, and revision, like this:
> svn:branch-from = /trunk:521
>
> That could be set for existing branches cheaply, and newer clients would do that
> automatically - for a "svn branch" command, at least :-)
>
>
> Regards,
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
I really like this idea! Existing clients and such could take the
info or leave it. I could also see how it might make some graphing
clients perform a little better, if not for showing all the merges
(which it can't do right now anyway) at least enough to show all the
branch points. Plus it would not take much to implement but has
potential for being very useful.
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Roy Franz <ro...@gmail.com>.
On Dec 14, 2007 7:29 PM, Branko Čibej <br...@xbc.nu> wrote:
> Karl Fogel wrote:
> > Branko Čibej <br...@xbc.nu> writes:
> >
> >> IMNSHO, we should first support the mainstream CM paradigm, then worry
> >> about edge cases such as yours. Having the branch and directory
> >> namespaces conflated is sexy for small projects but horror on
> >> moderate-sized ones. And on large projects, you end up inventing branch
> >> namespace hierarchy where the tool doesn't support it.
> >>
> >
> > I'm all for distinguishing formally between branches and copies, but
> > I'm not at all convinced it's problematic to have branches live in the
> > directory hierarchy. Kind of the opposite: I've liked it so far!
> >
> > This may be because I lack some important bit of experience. If so,
> > and if you have that experience, Branko, please share...
> >
>
> The second problem is semantics.
>
> It's not just about formally distinguishing between copies and branches.
> This goes deeper.
>
> I submit:
>
> * When you make a branch, you want all that merge-tracking machinery
> to kick in.
> * You want easy answers to questions like "what changed on this
> branch?" and "where did we branch from?" and so on.
> * When you make a copy, you may want to vaguely remember what you
> copied, but you don't want any merge tracking or history from
> beyond the point of copy.
> * The above is again different from a rename, which is abstractly
> almost like a copy and delete, except that you /do/ want all
> history ... the changes in the name of the object are
> coincidental. (Note how filesystems treat "move" and "copy" quite
> differently in terms of inode identity, ownership and access rights.)
>
> All of these are superficially UI issues, and we even support them in a
> way (remember --stop-on-copy?), but really more as afterthoughts. And we
> don't support tag semantics at all.
>
> -- Brane
>
>
I have to heartily agree with Brane, as the current paradigm has
caused us many headaches, and
I think than many developers here consider the move to SVN a
regression from CVS. Our biggest headaches have been with tags.
We often want to know what version of a specific file went into a
specific release (tag.) Even in the simple case
of the tag being made directly from trunk, this is very cumbersome,
and gets worse if if is made from a branch.
This used to be trivial in CVS, and this is a very visible regression
in usability.
Tools that draw revision graphs like tkCVS don't do the right thing in
SVN. (it takes some shortcuts to try draw the graph in SVN,
but fails in all but very simple cases.)
Any repository reorg makes these problems worse. Early on a user
deleted the 'tags' directory. No problem - just copy it from a
previous revision. This of course breaks tkCVS, adds another level of
indirection to find tagged revisions. We ended up doing a dump/load
and
skipping the revisions with the delete/copy to fix tkCVS. I think that
if some of these operations (delete tags, branches, copy from previous
revision) were done on the main SVN repository that there would be
more awareness of some of these problems.
I personally think that some of these basic usability issues are much
more important than offline operation, etc.
Roy
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
David Glasser wrote:
> On Feb 19, 2008 1:04 AM, Michael Haggerty <mh...@alum.mit.edu> wrote:
>
>> Karl Fogel wrote:
>>
>>> Steinar Bang <sb...@dod.no> writes:
>>>
>>>> But one thing I've never understood, is why they are "branches by
>>>> convention". You guys have a very flexible metadata system, no? So why
>>>> not put a property on the top dir of a branch or a tag, saying that's
>>>> what it is?
>>>>
>>> We might someday, but we weren't sure (right now) what we'd do with
>>> that. One of the nice things about a flexible metadata scheme is that
>>> you don't have to design all your features at once :-).
>>>
>> I've thought that it would make sense to add a property to the trunk
>> directory that indicates "this is a project root directory" (in the
>> sense that it is the root of a source code tree, typically the level
>> that users check out). The property would help scripts orient
>> themselves. Moreover, it would automatically get propagated when trunk
>> is copied to make a tag or branch, making it obvious (with no more work)
>> that *those* are also project root directories.
>>
>> The point of such a property would mostly be to serve as a line of
>> demarcation between the project/trunk/tags/branches namespace
>> interesting in the SCM world and the filename namespace interesting for
>> working copies, build tools, etc.
>>
>> If there were a standard convention and name for such a property, then
>> tool builders might start using it.
>>
>
> Of course, finding such properties, noticing updates to them, etc, is
> not actually trivial under the svn model (see the incredible amount of
> effort required to make mergeinfo inheritance work, and it still has
> some holes).
>
Precisely my point, and one of the things I ranted about in this thread
two months ago: the client shouldn't be doing the server's job.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by David Glasser <gl...@davidglasser.net>.
On Feb 19, 2008 1:04 AM, Michael Haggerty <mh...@alum.mit.edu> wrote:
> Karl Fogel wrote:
> > Steinar Bang <sb...@dod.no> writes:
> >> But one thing I've never understood, is why they are "branches by
> >> convention". You guys have a very flexible metadata system, no? So why
> >> not put a property on the top dir of a branch or a tag, saying that's
> >> what it is?
> >
> > We might someday, but we weren't sure (right now) what we'd do with
> > that. One of the nice things about a flexible metadata scheme is that
> > you don't have to design all your features at once :-).
>
> I've thought that it would make sense to add a property to the trunk
> directory that indicates "this is a project root directory" (in the
> sense that it is the root of a source code tree, typically the level
> that users check out). The property would help scripts orient
> themselves. Moreover, it would automatically get propagated when trunk
> is copied to make a tag or branch, making it obvious (with no more work)
> that *those* are also project root directories.
>
> The point of such a property would mostly be to serve as a line of
> demarcation between the project/trunk/tags/branches namespace
> interesting in the SCM world and the filename namespace interesting for
> working copies, build tools, etc.
>
> If there were a standard convention and name for such a property, then
> tool builders might start using it.
Of course, finding such properties, noticing updates to them, etc, is
not actually trivial under the svn model (see the incredible amount of
effort required to make mergeinfo inheritance work, and it still has
some holes).
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by David Glasser <gl...@davidglasser.net>.
On Feb 19, 2008 2:23 PM, Michael Haggerty <mh...@alum.mit.edu> wrote:
> Branko Čibej wrote:
> > Michael Haggerty wrote:
> >> I've thought that it would make sense to add a property to the trunk
> >> directory that indicates "this is a project root directory" (in the
> >> sense that it is the root of a source code tree, typically the level
> >> that users check out). [...]
> >
> > Reading this and similar proposals makes me want to cry. People keep
> > proposing hacks upon hacks upon hacks instead of recognizing the
> > fundamental truth that our branching model is broken.
>
> Brane, you already persuaded me at the SVN summit that Subversion's
> current branching model should be buried as an implementation detail.
> In fact, the branching model that I use in cvs2svn separates the line of
> development namespace from the file namespace just as you advocate
> because (1) it is simpler to implement; (2) it is a better match to CVS
> branches and tags; and (3) it is a better match to git's model, which is
> the other output SCM that we currently support. But given that the
> Subversion world isn't changing soon, a simple hack like this (almost
> zero work) might ease the pain a little bit. And in the unlikely case
> that SVN ever changes its branching model, something like the suggested
> property could help with forwards and backwards compatibility.
>
> David Glasser wrote:
> > Of course, finding such properties, noticing updates to them, etc, is
> > not actually trivial under the svn model (see the incredible amount of
> > effort required to make mergeinfo inheritance work, and it still has
> > some holes).
>
> True, but there are far fewer project lines of development than merges,
> and only one level of any SVN path in a conventionally-structured SVN
> repository should ever have this property. The most common questions
> would be: what line of development does this file belong to? (traverse
> path towards root until a project root directory is found) and what is
> the complete list of lines of development in this repository?
> (breadth-first tree walk starting at root and pruning whenever a project
> root is found).
I agree; in fact this matches my personal favorite model for a "sane"
svn copy/branch semantics. Just pointing out that, given svn's
client/server model, knowing the answer to those two "common
questions" in the client isn't always so easy. (Brane aptly points
out that this is a flaw in our choice of client vs server
responsibilities.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
Re: Reality check
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Branko Čibej <br...@xbc.nu>:
> No worries, Mike. This thread's archived, all he has to do is dig back
> a bit. :-P
Well... I haven't seen this thread and others, but I haven't seen you
describe the issues in a way that have made me understand what it is
broken with it...?
The tag-and-branch-with-a-copy thing was strange to me, when I first
started using svn, coming from a decade+ of CVS and RCS usage. But I've
gotten used to it, and now it's just the way subversion is.
What I didn't like back in 2001, and what I don't like now, is that it's
all based on conventions, which makes it hard for other front ends and
tools to figure out what's a branch and not.
Using metadata to say what's what, seems like a simple fix for that
issue, and one that can be done without changing the world.
A different world is not what I want from svn. If I want a different
world, I'll go with one of the new distributed source control systems.
FWIW perforce uses a similar model for branching, and svn's continuity
is better across branch copies, than perforce's
(not that I like perforce much, though... I have to use it at work)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
> Daniel Torreblanca wrote:
>>> Reading this and similar proposals makes me want to cry. People keep
>>> proposing hacks upon hacks upon hacks instead of recognizing the
>>> fundamental truth that our branching model is broken.
>>>
>>> Deal with it. I've had my catharsis and am all better now, no more
>>> jitters and insomnia. Highly recommended.
>>>
>>> -- Brane
>>
>> Forgive me for being new, but how is it broken?
>
> "No! Don't release the Bran-- Ah. Too late."
>
> cmpilato has room for about eleven more in his underground shelter.
> First come, first served.
>
No worries, Mike. This thread's archived, all he has to do is dig back a
bit. :-P
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by "C. Michael Pilato" <cm...@collab.net>.
Daniel Torreblanca wrote:
>> Reading this and similar proposals makes me want to cry. People keep
>> proposing hacks upon hacks upon hacks instead of recognizing the
>> fundamental truth that our branching model is broken.
>>
>> Deal with it. I've had my catharsis and am all better now, no more
>> jitters and insomnia. Highly recommended.
>>
>> -- Brane
>
> Forgive me for being new, but how is it broken?
"No! Don't release the Bran-- Ah. Too late."
cmpilato has room for about eleven more in his underground shelter. First
come, first served.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Reality check
Posted by Daniel Torreblanca <re...@gmail.com>.
On Feb 19, 2008 4:52 AM, Branko Čibej <br...@xbc.nu> wrote:
[snip]
> > I've thought that it would make sense to add a property to the trunk
> > directory that indicates "this is a project root directory" (in the
> > sense that it is the root of a source code tree, typically the level
> > that users check out). The property would help scripts orient
> > themselves. Moreover, it would automatically get propagated when trunk
> > is copied to make a tag or branch, making it obvious (with no more work)
> > that *those* are also project root directories.
> >
> > The point of such a property would mostly be to serve as a line of
> > demarcation between the project/trunk/tags/branches namespace
> > interesting in the SCM world and the filename namespace interesting for
> > working copies, build tools, etc.
> >
> > If there were a standard convention and name for such a property, then
> > tool builders might start using it.
> >
>
> Reading this and similar proposals makes me want to cry. People keep
> proposing hacks upon hacks upon hacks instead of recognizing the
> fundamental truth that our branching model is broken.
>
> Deal with it. I've had my catharsis and am all better now, no more
> jitters and insomnia. Highly recommended.
>
> -- Brane
Forgive me for being new, but how is it broken?
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> Branko Čibej <br...@xbc.nu> writes:
>
>> IMNSHO, we should first support the mainstream CM paradigm, then worry
>> about edge cases such as yours. Having the branch and directory
>> namespaces conflated is sexy for small projects but horror on
>> moderate-sized ones. And on large projects, you end up inventing branch
>> namespace hierarchy where the tool doesn't support it.
>>
>
> I'm all for distinguishing formally between branches and copies, but
> I'm not at all convinced it's problematic to have branches live in the
> directory hierarchy. Kind of the opposite: I've liked it so far!
>
> This may be because I lack some important bit of experience. If so,
> and if you have that experience, Branko, please share...
>
The first problem is repository layout.
Lets take a relatively simple example. We'll have a repository where we
store several code modules and some design documentation (which we don't
want to branch). OK, so the layout will be:
/
docs/
code/
trunk/
branches/
tags
Hmmm, wait ... I want each module to have its own lifecycle, and I want
a place for importing upstream stuff that's separate from other branches
... so ...
/
docs/
code/
upstream/
ModuleA/
trunk/
branches/
tags/
ModuleB/
...
(Note that I'm perpetuating the the illogical specialness of trunk, to
make things more confusing). Oh, then I want to make tags for upstream
imports (don't ask me why since they're not much use for merging); and
BTW, ModuleB is actually ProjectB and has its own submodules with
independent life cycles ...
/
docs/
code/
upstream/
tags/
ModuleA/
trunk/
branches/
tags/
ProjectB/
ModuleC/
...
ModuleD/
...
And so on. Soon you find that you need map and a full-time seer to find
your way through the mess. And one day you find that bits of ModuleA
have to be visible from ModuleD on a predictable relative path, which is
quite impossible because of all the intervening branch names, and you
can't use externals for that; absolute externals won't work for people
accessing the repository from remote (because of different names, for
example); relative externals won't because of all the intervening branch
names, and oh yes, every time you create a tag you'd /still/ have to
change all externals ...
So you give in, decide to take a huge risk to your multi-million-LOC
project and restructure the repository. This time you keep it as simple
as possible. All top-level directories are branches (br) or tags (tg),
everything uses the same branch structure, you always branch the whole
repository (it's cheap, right) and relative paths stay stable.
/
br.main/
docs/
code/
ModuleA/
ProjectB/
ModuleC/
ModuleD/
br.upstream/
code/
...
tg.0.10.4/
Nice. And looks suspiciously as if the top level of the repository is a
separate namespace. Add a task branch that is a subbranch of 'br.main',
let's call it br.main.task1 for the sake of argument ... pity I can't
call it main/task1, that would be even more obvious ... and an even
bigger giveaway.
The example above is anything but farfetched (I've seen all the steps --
except the last one :) -- repeated over and over).
I can hear the counter-arguments:
* "You can start with a simple structure and move things around later."
With the available merge and history tracking? Hollow laugh.
* "The last solution is not much different from the suggested
trunk/branches/tags."
Indeed it's not. Makes you think, why all that flexibility if you
end up with top-level branches and tags, or you end up going insane?
* "But, but ... our current way is more /flexible/!"
Right. In many cases flexibility is a curse. This is one such
case. Ask any ClearCase user what happens if you try to exploit
all of CC's flexibility.
Everybody keeps inventing myriads of similar-but-different solutions to
the branch-structure problem, the same mistakes are repeated time after
time exactly because of some flexibility that no-one really needs.
We managed to expose a sexy implementation detail as a first-class UI
paradigm. Imagine having a C compiler that requires you to manually
annotate invariants for the loop optimizer, or worse yet, wants you to
mark bits of code that can be candidates for branch-delay slot
scheduling. Feel the horror?
Let's stop congratulating ourselves and admit that branching and tagging
in Subversion are so flexible they hurt. Users want to say, "make a
branch" or "I'm working on that branch now" or "tag this for posterity."
Yes, these are basically user-interface things and "you can create
aliases and use shell variables" but that's again the user (not even
client) doing the server's job.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Karl Fogel <kf...@red-bean.com>.
Brane, you wrote two very detailed mails answering my question, and
ordinarily would get more than this brief "Thank you!" for your
efforts. However, I'm busily packing for a cross-country move, so
this grateful acknowledgement is all I can do right now. There are
various responses -- just responses, not necessarily counterarguments
-- I would normally make, but they'll have to wait.
-Karl
Branko Čibej <br...@xbc.nu> writes:
> The second problem is semantics.
>
> It's not just about formally distinguishing between copies and branches.
> This goes deeper.
>
> I submit:
>
> * When you make a branch, you want all that merge-tracking machinery
> to kick in.
> * You want easy answers to questions like "what changed on this
> branch?" and "where did we branch from?" and so on.
> * When you make a copy, you may want to vaguely remember what you
> copied, but you don't want any merge tracking or history from
> beyond the point of copy.
> * The above is again different from a rename, which is abstractly
> almost like a copy and delete, except that you /do/ want all
> history ... the changes in the name of the object are
> coincidental. (Note how filesystems treat "move" and "copy" quite
> differently in terms of inode identity, ownership and access rights.)
>
> All of these are superficially UI issues, and we even support them in a
> way (remember --stop-on-copy?), but really more as afterthoughts. And we
> don't support tag semantics at all.
>
> -- Brane
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> Branko Čibej <br...@xbc.nu> writes:
>
>> IMNSHO, we should first support the mainstream CM paradigm, then worry
>> about edge cases such as yours. Having the branch and directory
>> namespaces conflated is sexy for small projects but horror on
>> moderate-sized ones. And on large projects, you end up inventing branch
>> namespace hierarchy where the tool doesn't support it.
>>
>
> I'm all for distinguishing formally between branches and copies, but
> I'm not at all convinced it's problematic to have branches live in the
> directory hierarchy. Kind of the opposite: I've liked it so far!
>
> This may be because I lack some important bit of experience. If so,
> and if you have that experience, Branko, please share...
>
The second problem is semantics.
It's not just about formally distinguishing between copies and branches.
This goes deeper.
I submit:
* When you make a branch, you want all that merge-tracking machinery
to kick in.
* You want easy answers to questions like "what changed on this
branch?" and "where did we branch from?" and so on.
* When you make a copy, you may want to vaguely remember what you
copied, but you don't want any merge tracking or history from
beyond the point of copy.
* The above is again different from a rename, which is abstractly
almost like a copy and delete, except that you /do/ want all
history ... the changes in the name of the object are
coincidental. (Note how filesystems treat "move" and "copy" quite
differently in terms of inode identity, ownership and access rights.)
All of these are superficially UI issues, and we even support them in a
way (remember --stop-on-copy?), but really more as afterthoughts. And we
don't support tag semantics at all.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
philipp.marek@bmlv.gv.at wrote:
> Hyrum K. Wright wrote:
>
>> I have similar feelings. In working on some of the auditing code, I've
>> often thought "gee, if I could only tell if this copy is a branch or a
>> true copy." Having branches in directory hierarchy is very useful,
>> especially when browsing them using mod_dav_svn and my favorite web
>> browser. But the extra branch v. copy metadata would be useful.
>>
> How about just defining some extra property, that should be set to define some
> copy as a branch? Eg. "svn:branch-from" and some source
> (repository-root-relative) path, and revision, like this:
> svn:branch-from = /trunk:521
>
Oh ugh. Here's a square peg, I mean property, let's go find some round
holes for it.
> That could be set for existing branches cheaply, and newer clients would do that
> automatically - for a "svn branch" command, at least :-)
>
Are you quite sure you want to add another feature that causes the
client to do the server's job? Remember svn:externals and how useful
they are?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by ph...@bmlv.gv.at.
Hyrum K. Wright wrote:
> I have similar feelings. In working on some of the auditing code, I've
> often thought "gee, if I could only tell if this copy is a branch or a
> true copy." Having branches in directory hierarchy is very useful,
> especially when browsing them using mod_dav_svn and my favorite web
> browser. But the extra branch v. copy metadata would be useful.
How about just defining some extra property, that should be set to define some
copy as a branch? Eg. "svn:branch-from" and some source
(repository-root-relative) path, and revision, like this:
svn:branch-from = /trunk:521
That could be set for existing branches cheaply, and newer clients would do that
automatically - for a "svn branch" command, at least :-)
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
Hyrum K. Wright wrote:
> Karl Fogel wrote:
>
>> Branko Čibej <br...@xbc.nu> writes:
>>
>>> IMNSHO, we should first support the mainstream CM paradigm, then worry
>>> about edge cases such as yours. Having the branch and directory
>>> namespaces conflated is sexy for small projects but horror on
>>> moderate-sized ones. And on large projects, you end up inventing branch
>>> namespace hierarchy where the tool doesn't support it.
>>>
>> I'm all for distinguishing formally between branches and copies, but
>> I'm not at all convinced it's problematic to have branches live in the
>> directory hierarchy. Kind of the opposite: I've liked it so far!
>>
>
> I have similar feelings. In working on some of the auditing code, I've
> often thought "gee, if I could only tell if this copy is a branch or a
> true copy." Having branches in directory hierarchy is very useful,
> especially when browsing them using mod_dav_svn and my favorite web
> browser. But the extra branch v. copy metadata would be useful.
>
>
Let's distinguish between "looking at the repository with a web browser"
and "accessing the repository via an HTTP-ish connection." The cases are
orthogonal.
For the "looking at" part, try as I might, I can't see what's wrong with
having a separate repository-browsing server. The fact that you can
browse through a Subversion repository using mod_dav_svn is a wart
(which I admit I helped perpetuate). It gives the false impression of
being useful while at the same time giving the false impression that SVN
can't live without conflated branches and directories.
It's in fact a lot better to use dedicated severs like ViewVC (or hgweb,
hello competition) that can interpret what it sees in the repository and
has lots of bells and whistles. And keep the actual repository-access
server lean fast.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Karl Fogel wrote:
> Branko Čibej <br...@xbc.nu> writes:
>> IMNSHO, we should first support the mainstream CM paradigm, then worry
>> about edge cases such as yours. Having the branch and directory
>> namespaces conflated is sexy for small projects but horror on
>> moderate-sized ones. And on large projects, you end up inventing branch
>> namespace hierarchy where the tool doesn't support it.
>
> I'm all for distinguishing formally between branches and copies, but
> I'm not at all convinced it's problematic to have branches live in the
> directory hierarchy. Kind of the opposite: I've liked it so far!
I have similar feelings. In working on some of the auditing code, I've
often thought "gee, if I could only tell if this copy is a branch or a
true copy." Having branches in directory hierarchy is very useful,
especially when browsing them using mod_dav_svn and my favorite web
browser. But the extra branch v. copy metadata would be useful.
Re: Reality check
Posted by Michael Haggerty <mh...@alum.mit.edu>.
Branko Čibej wrote:
> Michael Haggerty wrote:
>> I've thought that it would make sense to add a property to the trunk
>> directory that indicates "this is a project root directory" (in the
>> sense that it is the root of a source code tree, typically the level
>> that users check out). [...]
>
> Reading this and similar proposals makes me want to cry. People keep
> proposing hacks upon hacks upon hacks instead of recognizing the
> fundamental truth that our branching model is broken.
Brane, you already persuaded me at the SVN summit that Subversion's
current branching model should be buried as an implementation detail.
In fact, the branching model that I use in cvs2svn separates the line of
development namespace from the file namespace just as you advocate
because (1) it is simpler to implement; (2) it is a better match to CVS
branches and tags; and (3) it is a better match to git's model, which is
the other output SCM that we currently support. But given that the
Subversion world isn't changing soon, a simple hack like this (almost
zero work) might ease the pain a little bit. And in the unlikely case
that SVN ever changes its branching model, something like the suggested
property could help with forwards and backwards compatibility.
David Glasser wrote:
> Of course, finding such properties, noticing updates to them, etc, is
> not actually trivial under the svn model (see the incredible amount of
> effort required to make mergeinfo inheritance work, and it still has
> some holes).
True, but there are far fewer project lines of development than merges,
and only one level of any SVN path in a conventionally-structured SVN
repository should ever have this property. The most common questions
would be: what line of development does this file belong to? (traverse
path towards root until a project root directory is found) and what is
the complete list of lines of development in this repository?
(breadth-first tree walk starting at root and pruning whenever a project
root is found).
I'm not saying that edifices should be built on top of a hack like this;
just that it would be a very easy way to keep track of project roots in
today's SVN in a not-so-terribly-inaccessible form.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
Michael Haggerty wrote:
> Karl Fogel wrote:
>
>> Steinar Bang <sb...@dod.no> writes:
>>
>>> But one thing I've never understood, is why they are "branches by
>>> convention". You guys have a very flexible metadata system, no? So why
>>> not put a property on the top dir of a branch or a tag, saying that's
>>> what it is?
>>>
>> We might someday, but we weren't sure (right now) what we'd do with
>> that. One of the nice things about a flexible metadata scheme is that
>> you don't have to design all your features at once :-).
>>
>
> I've thought that it would make sense to add a property to the trunk
> directory that indicates "this is a project root directory" (in the
> sense that it is the root of a source code tree, typically the level
> that users check out). The property would help scripts orient
> themselves. Moreover, it would automatically get propagated when trunk
> is copied to make a tag or branch, making it obvious (with no more work)
> that *those* are also project root directories.
>
> The point of such a property would mostly be to serve as a line of
> demarcation between the project/trunk/tags/branches namespace
> interesting in the SCM world and the filename namespace interesting for
> working copies, build tools, etc.
>
> If there were a standard convention and name for such a property, then
> tool builders might start using it.
>
Reading this and similar proposals makes me want to cry. People keep
proposing hacks upon hacks upon hacks instead of recognizing the
fundamental truth that our branching model is broken.
Deal with it. I've had my catharsis and am all better now, no more
jitters and insomnia. Highly recommended.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Michael Haggerty <mh...@alum.mit.edu>.
Karl Fogel wrote:
> Steinar Bang <sb...@dod.no> writes:
>> But one thing I've never understood, is why they are "branches by
>> convention". You guys have a very flexible metadata system, no? So why
>> not put a property on the top dir of a branch or a tag, saying that's
>> what it is?
>
> We might someday, but we weren't sure (right now) what we'd do with
> that. One of the nice things about a flexible metadata scheme is that
> you don't have to design all your features at once :-).
I've thought that it would make sense to add a property to the trunk
directory that indicates "this is a project root directory" (in the
sense that it is the root of a source code tree, typically the level
that users check out). The property would help scripts orient
themselves. Moreover, it would automatically get propagated when trunk
is copied to make a tag or branch, making it obvious (with no more work)
that *those* are also project root directories.
The point of such a property would mostly be to serve as a line of
demarcation between the project/trunk/tags/branches namespace
interesting in the SCM world and the filename namespace interesting for
working copies, build tools, etc.
If there were a standard convention and name for such a property, then
tool builders might start using it.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Karl Fogel <kf...@red-bean.com>.
Steinar Bang <sb...@dod.no> writes:
> But one thing I've never understood, is why they are "branches by
> convention". You guys have a very flexible metadata system, no? So why
> not put a property on the top dir of a branch or a tag, saying that's
> what it is?
We might someday, but we weren't sure (right now) what we'd do with
that. One of the nice things about a flexible metadata scheme is that
you don't have to design all your features at once :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Karl Fogel <kf...@red-bean.com>:
> I'm all for distinguishing formally between branches and copies, but
> I'm not at all convinced it's problematic to have branches live in the
> directory hierarchy. Kind of the opposite: I've liked it so far!
I agree.
But one thing I've never understood, is why they are "branches by
convention". You guys have a very flexible metadata system, no? So why
not put a property on the top dir of a branch or a tag, saying that's
what it is?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@xbc.nu> writes:
> IMNSHO, we should first support the mainstream CM paradigm, then worry
> about edge cases such as yours. Having the branch and directory
> namespaces conflated is sexy for small projects but horror on
> moderate-sized ones. And on large projects, you end up inventing branch
> namespace hierarchy where the tool doesn't support it.
I'm all for distinguishing formally between branches and copies, but
I'm not at all convinced it's problematic to have branches live in the
directory hierarchy. Kind of the opposite: I've liked it so far!
This may be because I lack some important bit of experience. If so,
and if you have that experience, Branko, please share...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
Vincent Lefevre wrote:
> On 2007-12-03 08:53:30 +0100, Branko Čibej wrote:
>
>> * Divorce branches from copies. Branch, tag and copy are all
>> conceptually different. Our simple "branch == copy" paradigm is
>>
> [...]
>
> Do you mean that it will no longer be possible to do a merge on a
> copy? For instance, I like to be able to do the following in the
> working copy containing my own files (the main part of my home
> directory, if you want):
>
> svn cp script script.test
>
> then do changes on script and experimental changes on script.test,
> and later merge the experimental changes to script. And it is quite
> useful to have script and script.test available at the same time:
> script must always be available for normal use, and script.test for
> testing.
>
> IMHO, branches should be regarded as a particular form of copies
> (i.e. with additional restrictions to allow more features).
>
IMNSHO, we should first support the mainstream CM paradigm, then worry
about edge cases such as yours. Having the branch and directory
namespaces conflated is sexy for small projects but horror on
moderate-sized ones. And on large projects, you end up inventing branch
namespace hierarchy where the tool doesn't support it.
What happens after that ... is too early to guess.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-12-03 08:53:30 +0100, Branko Čibej wrote:
> * Divorce branches from copies. Branch, tag and copy are all
> conceptually different. Our simple "branch == copy" paradigm is
[...]
Do you mean that it will no longer be possible to do a merge on a
copy? For instance, I like to be able to do the following in the
working copy containing my own files (the main part of my home
directory, if you want):
svn cp script script.test
then do changes on script and experimental changes on script.test,
and later merge the experimental changes to script. And it is quite
useful to have script and script.test available at the same time:
script must always be available for normal use, and script.test for
testing.
IMHO, branches should be regarded as a particular form of copies
(i.e. with additional restrictions to allow more features).
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> Branko Čibej <br...@xbc.nu> writes:
>
>> So ... we've made many wrong decisions, and I admit to making or
>> supporting quite a few of them. But I don't see any reason for
>> perpetuating them. So I suggest you (we?) all take a step back and
>> *seriously* start moving in the right direction [...]
>>
>
> Well, that's what we're trying to do. I understand that your mail is
> meant to be constructive, but a... little more specificity would be
> helpful :-).
>
In fact, I was hoping to provoke reactions to the tune of "let's show
this lazy idiot who hasn't written a line of code in a month of Sundays
what we're about!" Not a very orthodox approach in this forum, I'll
admit -- hence the "rude and ridiculous" -- but it's the best I can do
right now, and it did get some response in the right direction. :)
/In re/ more specificity: I think you'll agree that some aspects of the
Subversion architecture are seriously hindering the development of the
less trivial features. Yes, merge tracking is hard -- but we've been
actively helping to make it harder; and what I see as the holy grail of
Subverion-2.0, namely, true offline operation (including commits) and
cross-repository merging, is virtually impossible. (And note that I'm
not necessarily proposing a full DVCS!)
Whilst Subversion's view of the world may appeal to "the 80%" (thanks,
Ben!), I'm not very impressed by its usefulness for even
moderately-sized projects. I'd suspected this could be the case before,
but I've had this suspicion confirmed any number of times within the
last year or so -- much to my own detriment. Part of my frustration
certainly stems from the fact that I've not had time to do anything
about it.
So for now I'll throw a few bones that I and/or others have been talking
about for a while now:
* The repository architecture (schema, semantics and back-end
implementation) needs a complete overhaul. Refer to DannyB's and
my and others' presentations at last year's Summit.
* We do not have the resources to maintain two (or more!) repository
back-ends or four (or more!) access methods.
o Focus on /one/ repos backend -- the new one
o Drop WebDAV as a protocol spoken by the client. We're not
speaking real WebDAV anyway. If we need an HTTP-based access
method (and I believe we do, for firewall/proxy reasons if
no other), make it a RESTful variant of the svnserve
protocol instead.
o mod_dav_svn is useful for integration with non-Subversion
clients (autocommit is useful) -- but it should be limited
to that.
* The working-copy architecture ... (shudder).
* Divorce branches from copies. Branch, tag and copy are all
conceptually different. Our simple "branch == copy" paradigm is
indeed a low hurdle for people coming from SouceSafe or no VCS at
all (wait, aren't those the same?) ... but is a total pain for
project management. The number of hoops one has to jump through
and "don't do that!" recommendations one has to follow to get and
maintain a marginally sane repository structure is a serious hint.
* Last but not least ... We should stop fiddling about with
object-oriented code written in C. Our approach is only slightly
better than the horror that is GObject. If we must stay with
native-compiled libraries, let's do it in C++ ... in the last 7
years, GCC 4 and Visual Studio 8 have arrived, so most of our
original arguments for sticking with C no longer apply.
"Ceterum censeo Carthaginem esse delendam."
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reality check
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@xbc.nu> writes:
> Let's face it. 4 years after 1.0, and a year after our svn-2.0-focused
> summit, Subversion is treading water. In the last two years, have we
> added *any* feature that's more useful than the code bloat it produced?
I think this is rather too pessimistic.
- sparse directories
- interactive conflict resolution (not original to us, of course)
- relative svn:externals
Of course, the big feature is merge-tracking, and I think your
complaints there are fair, but a large part of the delay is that we're
trying to hit more use cases right out of the gate (e.g., truly
arbitrary cherry-picking).
> We've not even solved the relatively simple problem of working correctly
> on case-insensitive filesystems -- which just happens to include about
> 99% of all computers in the world, according to latest estimates. Many
> version control projects that didn't even exist when svn-1.0 came out
> have caught up and surpassed Subversion in terms of version control
> functionality, performance and (!) reliability, while we've wasted time
> with non-profit corporations and trademark protection.
That I can't agree with. We didn't spend *so* much time on that, and
a lot of what we did is stuff that any project would have to do once
it achieves a certain level of popularity. (There were some genuine
identity confusion problems going on -- ones that could actually hurt
users -- before we started getting serious about trademarks, as you
know.)
> I'm not going to try to analyze the reasons here, except to note that
> losing sight of the ball does not help, nor does resting on laurels.
> Quite frankly, if I were setting up a configuration management
> infrastructure from scratch today, I'd probably not select Subversion as
> the version control system; that's how far things have gone off course.
If I were setting up a system for an open source project to use, I'd
have to examine a lot of factors (not just hot air, btw: for some
time, I've been advocating that the FSF switch GNU Emacs from CVS to
Git or Mercurial, because those would likely be the best tools for
that particular job).
But for enterprise-level version control, across a large organization
and a diverse set of users? Subversion, no question about it.
> So ... we've made many wrong decisions, and I admit to making or
> supporting quite a few of them. But I don't see any reason for
> perpetuating them. So I suggest you (we?) all take a step back and
> *seriously* start moving in the right direction [...]
Well, that's what we're trying to do. I understand that your mail is
meant to be constructive, but a... little more specificity would be
helpful :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org