On Monday 1 Aug 2011, Ulrich Eckhardt wrote:
> On Friday 29 July 2011, Brecht Ameije wrote:
> > I read the referred page in the book, indeed: the script
svn_load_dirs.pl
> > is exactly what I need. It implements the steps that I did by hand.
>
> There is one thing that took me a while to understand when starting to use
> that: This doesn't preserve your local changes. Instead, after uploading a
new
> upstream version, you have to apply your local changes again. Merging
helps
> though.
>
> > But when I try it, I doesn't work as flawless as I thought it would:
> > It dumps a list with all added/deleted files and gives each of them a
> > number.
> > Than you have to manually connect the correct numbers to say which ones
> > are actually renamed files. A very tedious job, as there are +100
different
> > files and the lists aren't even sorted alphabetically :(
>
> I agree. If you know Perl, you might come up with something
different/better
> or just more suitable for your case.
That's the nice thing about scripts. Maybe one day...
>
> > Running /usr/bin/svn add -N --targets
> > /tmp/svn_load_dirs_W1GIx88wmF/targets.00001
> > /usr/bin/svn_load_dirs.pl: /usr/bin/svn add -N --targets
> > /tmp/svn_load_dirs_W1GIx88wmF/targets.00001 failed with this output:
> > svn: warning: 'TODO_unicode@' not found
> > svn: warning: 'include/ar.h@' not found
>
> The at sign has a special meaning in SVN URL, it is used for peg
revisions.
> Question is, are there files with a trailing at sign in the tree that you
want
> to import? If yes, they are not handled correctly. If not, wrong filenames
> have been generated at some point. It is probably a bug either in the
import
> script or SVN itself.
The original file names don't have the at sign in them. It must be atted by
the script ;)
>
> > Cleaning up /tmp/svn_load_dirs_W1GIx88wmF
> > (in cleanup) cannot chdir to
> > /tmp/svn_load_dirs_W1GIx88wmF/my_import_wc from
> > /tmp/svn_load_dirs_W1GIx88wmF: No such file or directory, aborting. at
> > /usr/bin/svn_load_dirs.pl line 2056
>
> This looks strange. I know I had issues with virus scanners during
imports,
> but I never managed to fully explain why and when.
No virus scanner here.
>
> > The 'not found' files, are actually the files that are added in the new
> > vendor version.
>
> Those with the trailing "@"?
Yep. But again, they don't have the at in their name.
>
> > The 'no such file or dir' is in one of the two renamed folders
> > ('archival/libarchive') that I marked for renaming...
> > Seem like the script is looking for them in my working copy, but they
don't
> > exist (yet).
>
> The script is checking out a working copy, then copying the version to be
> imported over it. For any missing/added files, it then prompts you if
those
> were new file or if they were moved etc. It then performs the according
"svn
> add/move/delete" calls and commits the new version. It shouldn't be
looking
> for anything in already existing working copies - did you perhaps run it
> inside a working copy?
>
> Uli
Hmm, true, I was running it inside a working copy. So I hoped that would be
be the issue. But after running it again from another dir, I noticed 2
things:
- the problem persists: the script aborts with the same errors
- before aborting, aparently the script had already committed all rename
actions.
So I guess the script acts in 2 stages:
1. The script is checking out a working copy. Before copying the version to
be
imported over it, it will check both versions for any missing/added files,
and
prompt you if those were new files or if they were moved etc. It then
performs
the according "svn rename" calls and commits the renames.
2. Only now the script wil copy the version to be imported over the working
copy.
And then it will commit these changes.
For me stage 1 worked nicely, the errors happened in stage 2.
Stage 2 is easy to do by hand, so that's what I did.
Conclusion:
The script is not much better than doing it all by hand. It's possibly
more usefull on smaller projects. So taking the bugs (at-signs, others?)
out,
and making the file-compare prompt easier to handle would really be an
improvement.
Thanks all for the input.
Also thanks to Andreas and Stefan. I'll leave Git to the professionals ;)
Brecht
Received on 2011-08-02 10:47:00 CEST