On May 27, 2009, at 07:53, Jimi H wrote:
> I have just recently found the svn script svn_load_dirs.pl and I
> think it is a real time saver when I now need to do some "vendor
> drops" in a project I'm working on. However, I noticed a somewhat
> annoying thing with the script.
>
> In the vendor drop I am trying to create now, there are quite alot
> of new and deleted files according to the script, about 700 lines
> of output. After some analyzing of the output I have identified
> about 30 renamed files scattered all over these 700 lines. So I put
> all the 60 or so lines with renames (corresponding to 30 or so file
> renames) in a text file in a separate window, to make it easier to
> find the indexes. Then I started to enter the indexes for the
> script. After each index pair I noticed that the script wanted to
> print the file list again, something I didn't really see the need
> for, but I just ignored it and continued to enter index pairs. But
> after just a few renames I noticed that the script was renaming
> completely different files then I had told it to. It was then that
> I realized that it performed the rename operation after each input,
> and then removed these rows from the list, which resulted in that
> all following rows was "moved up" and got new indexes.
>
> Can someone explain for me why the script works in this way? How am
> I supposed to keep track of all the files if the indexes keep
> changing? Do I have to let the script print all or part of the file
> list after each rename? With many of the renames at the end of the
> 700 line long list, that would be alot of tedious work.
I think that was the intended way to use it, yes. Yes, it can be
tedious if there are a lot of files.
What may not be immediately obvious is that the files are sorted by
just the filename, not by the whole path. The reason is presumably
that if you have a file foo.c that has moved, it might perhaps been
moved to a file foo.c in another directory. So you can just look for
foo.c in both listings and type the numbers. This is less useful if
you have a whole bunch of files with the same names; in my case I had
a whole bunch of Makefiles.
> The way I see it, the script would be much more useful if allowed
> the user to enter multiple index pairs in one go (and maybe
> printing the resulting rename without actually doing anything yet)
> and then do the all the renames as a bulk operation afterwards.
An option I had seen before but had not used until a few days ago is
the -wc flag. You can check out a working copy of your vendor
project's "current" directory from your repository, and perform these
"svn mv" renames yourself. Then when you run svn_load_dirs.pl, use
the -wc option to point to that working copy. It will then no longer
list those items in the list that you have already moved, and when
you're done and you tell it to proceed, it'll include those renames
in its commit.
This was useful for a project I was importing where a reorganization
had taken place and a half dozen directories had been renamed and
moved. It was much easier to do 6 manual "svn mv" commands in the
working copy for these directories than to match up over a hundred
individual file renames, which is how svn_load_dirs.pl presented it
to me.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2355830
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-27 18:51:23 CEST