On Fri, 09 Aug 2013 20:33:59 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
On Fri, Aug 9, 2013 at 8:24 PM, j. van den hoff
<veedeeh...@googlemail.com>wrote:
to different or newly created dirs: I'm not sure whether such a `mv' is
any
different from renaming the file itself?)
A mv is a rename, and Fossil remembers it all. In Unix (not sure about
Windows), a 'mv' is also just a rename unless the target is on another
filesystem, in which case it is a copy-then-delete. If you do a bunch of
renaming/moving, but do no edits, you might be surprised how little data
fossil has to save. i had a commit a day or two ago with about 15 renames
and the push reported only 2000 bytes sent.
yes, sure (I'm only talking about unix, anyway...) I just was not sure
whether this makes any difference as far as fossil is concerned. I would
suspect
that this sort of "renaming" (moving files to different directories) is
happening quite often in modestly large projects.
The other part of the problem is that I do most of the implementation
for
things like this and I rarely ever rename files in a project, so
diffing
between two versions of a file whose name has changed is not something
that
comes up for me very often, and hence is not a priority. You are more
again, you decide that (whether or not important to you). I suspect it's
not the majority view, though. and PR wise the competitors usually make
quite a big point of diff tracking capabilities across renames.
FWIW, i second Richard on this. It's so rarely needed (for us, at least)
that it's not worth the effort to implement. git is scary smart about the
movement of content between files (at the sub-file level, even), but for
projects of the scale/scope Fossil was designed for, that seems like
overkill. i honestly remember a single time i've thought, "man, if i
could
only diff those two renamed files." And if i did, i'd just check them
both
out and run them through my local diff/compare tool.
sure, but it is not quite what you would have liked to have in that moment.
and that "man, if I could" moment might happen quite often, wenn summed
over
the user community.
would be willing to do that if I were more fluent in C (let alone
anything
sql) than I am these days.
You don't need much SQL to work on Fossil, and there's much to learn
about
it from fossil. Copy/paste gets you a long ways, too. i'm certainly no
SQL
guru. But without C... we'll just have to accept your patches in the form
of course I do know C soso but haven't used it seriously in many years.
so I'm quite sure it would not be the best idea to dive into the fossil
code
right now and to mess it up. ;-)
of email text descriptions ;).
that's what I did I thought? I mean the question really is: is this a big
change to the code
or is the bottleneck to _understand_ what to do (because in the latter
case one of the
developers might need an hour where someone else needs a month or
whatever).
and to be clear: I did not try to "demand" such a change. I just think it
would
make fossil a better program if it had this functionality.
j.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
