> message. You can imagine the trivial arguments such as "get a better
> filesystem", "fix your tools", "use 'svn export' for builds, not a
Believe you me, I wish I COULD get a better filesystem. But I can't.
This is an old product. It doesn't even have vnodes, so I can't even
BUY filesystems like vxfs, let alone port any of the free ones. But
thank you for the tip on svn export. I missed that, and you are right,
for build machines that indeed fixes the problem completely. It MAY
even fix it for developers too. Since most of the tree is read-only
to most developers, perhaps they can export the tree, and then
svn checkout those portions where they will be doing real work. Is
there any problem with mixing and matchign exported and checked out
trees? I ask before I try because that's easier :)
> And this really doesn't sound trivial to get done. Elimination of
> text-bases is a nice thing - but the elimination of the need to
> traverse is what makes it a killer feature. I hope you can come up
> with a reasonable solution to this.
How about this. All we need is easy access to the very root of a
tree. I don't know what functions exist to find it but I am sure
they must exist, or would be trivial to implement. Once we can, from
within in WC, get an easy pointer to the root, all we need to do is
store a simple file in the root's admin directory of files edited.
This would make an "svn editing" command (to show what files are
being edited) a trivial case of cat-ing that file, and a commit
from the root a trivial case of commiting just the files in that
database. What gets trickier is if you do an svn commit from
somewhere OTHER than the root. At that point, we would either have
to resort back to traversal, or get clever with the entries in
the "being edited" list and determine which of them fall below
the current directory when the svn commit was run.
At all times, of course, the user should be able to commit just
a subset of the edited files. I frequently start work on one
bug, get pulled aside to fixing an escalation or helping with
packaging or whatever, and only need to check in a portion of
the files I have edited. But nothing I am suggesting precludes
that.
The notion of being able to get a list of all changed files quickly
is a very useful one. Especially in the case I described above,
where I may have edited files to solve more than one bug, but I
want each changeset to represent the fix for an individual bug.
Being able to:
$ svn editing > /tmp/foo
$ vi /tmp/foo ... remove everything I don't want checked in
$ svn commit `cat /tmp/foo`
is very useful, and, I suspect, frequently wished for. Yes it
is possible now but it traverses the tree, and when you are
talking large trees, that's a large penalty.
Kean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 17 11:55:20 2002