Excuse me butting in, because I'm not (yet) a committer, but a similar
discussion of svn client shortcomings was brought up in the user list,
and I thought some of the points there are pertinent. I have even
declared that I am personally giving up on using svn clients, and I am
moving my company to all use SVK as the main (or only) client, due to
its earlier implementation of some of the features being discussed
here.
On 1/17/07, David Anderson <dave@natulte.net> wrote:
> The first is that this is a 2.0 feature. I disagree for several reasons.
I don't care what version number these changes come in. I wont be
using any svn client version until a central WC cache of some sort is
implemented. Updates are just too painful with large NTFS tree crawls
right now. Commits are worse. I need to hack SVK to add Lock
capability, but once that's done, it has everything I need, through
its "svk mirror" implementation.
> IOW, I think this is as much a compatibility break as FSFS was for BDB
> backend users
I like that thought. While new options always add maintenance
overhead, such a diverse user base requires diverse customization
options.
> Which brings me to the maintenance burden issue that was raised. As I
> have said, I am willing to put changesets where my mouth is and make
> this happen.
I am currently working on an internal implementation of changesets.
Right now I am structuring each "changeset" as a named local branch of
an SVK mirror branch. All "changeset additions" are commits to that
branch. At the time of changeset commit, the changeset branch is just
smerge'd with the mirror branch. To me, changesets are just locally
administered patches, or "commit file lists" in the most trivial case,
with some nice labeling and tracking features, until time of commit.
I'm still interested to hear other's definition of "changeset".
> Regarding the proposed storage mechanism: I'm with Justin on the not
> storing anything outside the working copy by default. I like my
> self-contained working copies that I can delete without "detaching"
> them or some such nonsense.
I think David Glasser already mentioned, SVK can go both ways (~/.svk
or trunk/.svk). I don't mind the time it takes crawling up parents in
a tree to find the WC (this is always a straight line, and much faster
than the endless forking down crawl that is used now). I do like the
option of a one-stop-shop WC. I even hacked SVK locally to always
refer to a system env var ${SVKPATH} to look for the .svk WC store --
so that I can have a per-machine WC cache instead of a per-user WC
cache. As I said, I like options.
I think the easiest work-around to having a separate "detach"
command is just defining the command "svn mv trunk new-trunk-pos", or
even "svn mv folder new-folder-outside-WC". The first case would
change the local path reference for the "trunk" WC entry, but not
change anything in the repository or status otherwise. The second case
command would be just like the "svn sever blah new-blah" command you
mentioned before (which is a bit close to "svn server" in appearance
for my taste..).
> complicates the design for no net improvement that I can see. If you
> want stuff in ~/.subversion, then put the metadata there and symlink,
> and you're golden.
This "symlink option" eliminates the point of having a central
(per-user or per-machine instead of per-WC) cache in the first place
-- preventing the constant "crawl up until .svn found" check,
especially in GUIs like TortoiseSVN. This is much better and faster
than the "crawl and status down every fork" that TortoiseSVN does now,
but it is not the /optimal/ case for WC path search.
> Finally, regarding `svn edit`. After thinking about it some more, it's
> true that this feature is somewhat a separate issue to that of
> revamping the working copy.
One work-around to not having an explicit "svn edit" built-in might be
an "svn update --set-read-only ." option of some sort. Then I could
write wrapper scripts that use some locally maintained text list of
all "edit touched files", and chmod +w them after any update or lock.
I would chmod -w the files, and delete them from the text list, any
time they are included in a commit. Of course, this is a local hack
that wouldn't follow major "svn mv" or "svn sever" operations easily
(more wrapper scripts required), so "svn edit" is still preferable.
> I'll start drawing up a more detailed design tonight, to flesh out the
> general ideas.
I almost forgot -- THANK YOU! I hope this helped.
:) Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 20 03:03:15 2007