Hi Greg -
> When I say "we" below, I'm giving my best understanding of the consensus
> of the Subversion development community. I don't have any special
> authority to speak for the project.
Thanks for your quick response!
> > 1) .svn/ directory locations
>
> Right now we're explicitly not allowing features which complicate
> libsvn_wc, because it's not our most shining example of design quality.
> (We expect to see it redesigned after 1.0 is released.)
>
> This particular feature may not be high on the list of things to add
> even after 1.0; it adds significant complexity (both user-visible and
> internal) and doesn't add a great deal of value, although MacOS people
> would probably love it because it would go partway towards solving their
> collections problem. (Only partway, because for collections you also
> want the version control system to notice file additions and deletions
> automatically, instead of relying on explicit notification.)
I understand your concern about libsvn_wc. To address the
complexity issue, my intent is to effect the changes with a
minimum amount of code. I will investigate this matter and see
what is possible in this regard.
I have to make this patch (at least on a private copy) anyway,
because I actually need this feature now. I am happy to send the
patch to the list for comment, just in case the group decides
that it's not such a big change after all.
> > 2) Explicit edit support
>
> Although still subject to the constraints above, this feature is
> relatively high on the list of things to add post-1.0. It is a
> necessary step along the way to explicit locking support, could help us
> support much faster working directory crawls (faster status, diff,
> commit, etc.), and could help eliminate the text-base penalty without
> sacrificing network bandwidth.
>
> (Of course, it would have to be an option; the CVS "always-writable"
> model is very convenient for some developers. I'm thinking rather than
> a config file option, it would be a checkout option, with some
> corresponding metadata in .svn/entries. Though there could be a config
> option to set the default checkout behavior, I suppose.)
Same comment as 1) above: I'm hoping that it should not take
much code to do this in a basic way:
- svn edit is simply 'chmod +w FILE'
- svn revert has to do 'chmod -w FILE'
- svn commit has to do 'chmod -w FILE'
- svn update has to bring it in as read-only
- svn status has to check file permissions to get the 'U' tag
If there is anything I'm missing, do let me know. Again, this is
a feature I need right away, so I'm probably going to have to
make the patch, at least on a private copy.
> > 3) Editing of the commit list
>
> We've gotten as far as having a finished patch for this (or very close
> to finished, anyway), but consensus turned against adding that feature
> at the last minute. Or at least, consensus in favor of it failed. I
> was kind of bummed; it seems like a useful feature.
I'm curious - what was the reasoning behind this? Was it a
complexity issue, or something else? I can probably live without
this for now, but I will certainly like to have it in the near
future.
> > 4) External diff utility
>
> We have that already, don't we? diff-cmd and friends in
> ~/.subversion/config.
Unfortunately, this is broken for TkDiff and others that have
only a simple command-line interface. Maybe the right thing to
do is to add a 'diff-cmd-is-simple' config variable which causes
SVN to invoke the external diff command as just 'diff FILE1 FILE2'
Regards,
Kumaran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 23 02:58:20 2003