You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@red-bean.com> on 2007/12/03 00:11:14 UTC
Re: Reality check
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
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