Open GoogleCodeExporter opened 8 years ago
I think what is happening is /root/FolderA is interpreted as removing the file
'FolderA' from the directory '/root/'. It's probably reasonable for Gource to
check
if there is a directory with that path and remove that instead.
Gource assumes all paths it is given from a log file end in files.
Is this an SVN repo? What script did you use to generate your log? Did you use
svn-gource.py with the --filter-dirs option?
I would quite like to tidy up the SVN support, partly because the contributed
script
is written in python which I'm not really that interested in learning.
Cheers
Original comment by acaudw...@gmail.com
on 12 Jan 2010 at 9:53
Yeap, it's an svn repo converted with svn-gource.py without --filter-dirs
option. With
--filter-dirs as far as I remember everything is even worse: folder actions are
completely ignored insead of expanding them as list of actions with chidren
files.
Original comment by buryak.a...@gmail.com
on 12 Jan 2010 at 9:59
Ah ok. I think understand now.
I might have a go making a smarter SVN conversion script in perl.
Original comment by acaudw...@gmail.com
on 12 Jan 2010 at 10:14
I've written small ruby script that fixes data produced by svn-grouce.py - it
adds
children files removal commands on folder remove.
But it's not perfect. For example "svn folder copy" will not be correctly
processed
since it also have one command in log and no source path info (original svn log
has
such info, but it's cut out by svn-gource.py) ~_~`
Original comment by buryak.a...@gmail.com
on 12 Jan 2010 at 10:19
Attachments:
[deleted comment]
Cool someone might find that useful.
Could you post an example of an 'svn folder copy' log xml entry?
Original comment by acaudw...@gmail.com
on 12 Jan 2010 at 10:41
In subversion xml log it's something like this:
<path
copyfrom-path="/trunk/newfoldername"
copyfrom-rev="123"
action="A">/trunk/oldfoldername</path>
Original comment by buryak.a...@gmail.com
on 20 Aug 2010 at 7:47
Thanks for making a donation :)
I've been meaning to add support for renames so I will address directory
actions too.
Original comment by acaudw...@gmail.com
on 21 Aug 2010 at 2:39
Thanks for your great work :)
Original comment by buryak.a...@gmail.com
on 21 Aug 2010 at 8:07
Hi!
I really like your projects and spent some time playing with it on some svn
repositories.
As Alexander I remarked that folder deletes and copies (including moves,
renamings, branching...) were not handled correctly.
So i built a Java program that parses a svn xml log and "fixes" it by
recursively adding the same commmands to subdirectories and files of a copied
or deleted directory.
Here are the source files. The program needs jdom and takes one argument, the
name/path of the log file.
It outputs three files : the old and new version in a pretty format for easy
diff, and the new version in a format compatible with gource (for some unclear
reason the pretty formated xmls fail when input into gource).
I will be glad to get your comments/suggestions/fixes.
Anyways, thanks for this great, poetic, beautiful, useful work!
Original comment by julien.d...@gmail.com
on 8 Apr 2011 at 10:32
Attachments:
Thanks Julian!
Hopefully people will find this useful until I address this in Gource. I added
directory deletion handling for SVN logs in 0.30 (assuming this works), but I
have not added support for the other SVN specific commands yet.
I have made some assumptions about the format of the SVN xml file in order to
'seek' into it at any point and find the next commit (the closing '</logentry>'
tag must be on a new line for instance), which might be why your XML doesn't
parse.
Cheers
Andrew
Original comment by acaudw...@gmail.com
on 9 Apr 2011 at 5:19
I would like to see improved support for folder renames and moves in this great
visualization tool, as it is the most dissatisfying piece at the present time,
IMHO. When a folder is renamed, the folder link and its name (if visualized)
should simply flash. If a folder is moved to another location, the simulation
currently "explodes", whereas a more satisfactory result would be for the link
to be reattached to the new location, with the simulation "pulling" the rest of
the tree to the new location. Something similar might be done with individual
file moves, with the file visualizers sliding over to their new locations.
I'm using Git, in case that has any bearing on the issue.
Original comment by TLassan...@gmail.com
on 24 May 2014 at 4:59
Original issue reported on code.google.com by
buryak.a...@gmail.com
on 12 Jan 2010 at 8:23