Posts in category svn

Learning git

I've been using subversion for at least a decade now. I was going to switch to a git-based project so wanted to learn. I think I finally get the differences, especially with the "index." These are the resources I used:

And finally:

Using Kompare

So I was using Python to do some pretty diffs (will post that some time soon) and a coworker pointed out the program Kompare on Linux. I don't normally use Linux as a desktop, only servers. Anyway, it gives me an awesome interface, almost as good as the TortoiseSVN diff viewer I am used to. It can take the output of svn diff and then will find the original files and show you graphically all the changes.

The command I have been using: 

svn diff | kompare -o -

Using UltraCompare with TortoiseSVN

​From "Nick's Head Sphere" 

Diff:
C:\Program Files\IDM Computer Solutions\UltraCompare\UC.exe -t %base %mine

Merge:
C:\Program Files\IDM Computer Solutions\UltraCompare\UC.exe -rom %theirs %mine %merged

Subversion from Perl

So I spent about three hours trying to get my perl svn_compress script running and I ran kept running into the damned thing segfaulting!

svn_path_basename: Assertion `is_canonical (path, len)' failed.

I finally found the answer. Apparently, libsvn wants '' as the current directory, not '.' like every other program since the beginning of time (Jan 1, 1970, right?).

Three hours.

​Where I read the answer. Pasted here: 

Peter Samuelson wrote:
> [Julian Gilbey]
>> burnside:~/debian/tex/tetex-bin $ perl -MSVN::Client -e \
>>   'sub print_names { print "<$_[0]>\n"; } $ctx=new SVN::Client;
>>   $ctx->status("", "BASE", \&print_names, 1, 1, 0, 1);' | head -5
>> <>
>> <.pc>
>> <.pc/.version>
>> <configure>
>> <INSTALL.generic>
> 
> I reproduced your bugs with subversion 1.3.0-5, so I can properly
> discuss it with upstream.  Unfortunately, I don't know much about the
> Perl bindings.  But comparing "svn status" with your command, it does
> seem to correspond to the "." entry.  I wonder if that is even
> considered a bug.  I mean, if you prefix each entry with $(pwd)/, it is
> fine.
> 
> 
>> perl: /tmp/buildd/subversion-1.2.3dfsg1/subversion/libsvn_subr/path.c:377:
>> svn_path_basename: Assertion `is_canonical (path, len)' failed.
> 
> Right, that's definitely a bug.  Even if this isn't something the perl
> bindings can fix on their own, they should carp or something.

Hi. This is an issue that gets kicked around on dev at svn from time to
time, and usually ends up with the thread fizzling out sooner or later,
with no concrete action being taken, due to a lack of an obvious right
way to proceed. I'll sum up the situation...

There exist a number of path manipulation functions (svn_path_*) which
do not conform to the usual style returning an error status as the
return value, and output data via output pointer parameters. Instead
they return data directly as the return value, and are supposed to only
ever be able to experience errors that merit assert() or abort().

Subversion defines a 'canonical path' format, and most of the functions
(apart from the canonicalizer itself, obviously!) assert that the input
path looks like a canonical path.


Various groups of C programmers will conduct heated debates on whether
this is good programming practice, or an annoyance, but that is
irrelevant where the bindings are concerned, since assert()-ing out of a
scripting language interpreter is clearly bad.

There is a fairly obvious, though non-trivial, solution:
Make the bindings test all input paths (presumably using a path-specific
SWIG "in" typemap) using the same logic as is_canonical, and
canonicalize if necessary. The problem, though, is that discussions of
this nature tend to get intertwined with the parallel issue of whether
the C code is being generally unhelpful in this situation, and should be
changed too.


OK, now you know the background.

Feel free to prod dev at svn to raise awareness of this problem which has
sadly lain dormant for far too long.


Max.

Aside:
The canonical form (IIRC) is mostly common sense stuff:
* no repeated slashes
* no internal /../ sequences
* no trailing slash
BUT it has one weird rule:
* the canonical form of "." is ""

Compressing Subversion checkouts

I'll let the file intro explain itself: 

# "Disk space is cheap!" - SVN Authors
# "Except when backing it up!" - RevRagnarok

# This script will drastically reduce the size of an svn checkout so you can back up the folder.
# It will include a script to re-expand the directory with NO interaction with the server.
# It will also (optionally) write a script /tmp/svn_uncompress.sh that will restore all compressed
#   folders.

Something to check out in the future: ​http://scord.sourceforge.net/

Update 3 Apr 08: Updated the script to touch a file saying it ran so it won't run again. Also have it dump a tiny "readme" file to let somebody else know what is going on.
Update 4 Apr 08: Fixed bug with deep paths.
Update 22 Aug 08: Huge changes, now using "proper" native calls.

Unerasing files with subversion

​in the redbean book:

  • svn copy -r 11 file:///tmp/repos/test/trunk file:///tmp/repos/test/tags/0.6.32-prerelease -m "Forgot to tag at rev 11"

So, I think in our context, the file was deleted in revision 99 and we are now at 300: (in the trunk/src directory)

  • svn cp -r 99 http://srv/proj/trunk/src/filename filename

Using SVK for Roaming SVN Users

I have a Trac/SVN server on my work laptop (in a VMWare box). Others are needing access to the files more, so I needed a way to have two way merging. Of course, others have had this problem already, and svk was the result. However, there are certain aspects of svk that I'm not too fond of. Mainly, I didn't want to lose my TortoiseSVN capabilities or all my subversion know-how. However, I'm going to exploit the fact that an svk "depot" is under the hood a svn repository.

Here's what I did:

  1. I needed to get svk running under Cygwin. That was a real PITA, but luckily, somebody was nice enough to put all the instructions on ​this wiki page.
  2. Now I need to get a local copy of the entire svn repository under svk:
    • svk mkdir svnrepo
    • svk mirror http://svnserver/svn/path/to/repo //svnrepo/reponame
    • svk sync -a (This took FOREVER)
    • svk mkdir local
    • svk cp //svnrepo/reponame //local/reponame

OK, so now, we have a local svk "depot" which has in it /svnrepo/ and /local/ but it is all kept in a single svn repository on your hard drive. Now, the magic: we check out from that file using TortoiseSVN to create a subversion working copy. Using TortoiseSVN, I checked out "from" file:///E:/cygwin/home/user/.svk/local/local/reponame - you'll note that the first part is my cygwin home directory (username of 'user'), and the double local is not a typo - the first is a "real" directory on my E: drive, the second is at the root level of the repository (that we made above).

Now, when I'm offline, I can just use my local working copy, and am able to check in as much as I want without any worries. Another use for this I read about was if you want to check in a lot more than your coworkers do and want to keep the "master" repository "clean."

To perform the actual sync with the master server:

  • svk pull //local/reponame (This makes sure the local svk depot is in sync)
  • svk push --verbatim //local/reponame
    • The verbatim flag prevents svk from inserting its own header which was causing problems with trac by pointing to revision numbers in the future which just made no sense.

Drawbacks

  • One of the files I tried to push was locked on the master repository, but that information doesn't seem to be propagated properly, so the push failed until I unlocked the file manually on the master server.
  • Need to do the push and pull manually.
  • svn's keyword substitution now replaces info with local information, like revision number of the file in the local svk depot, not the master repository (which means printouts aren't going to match). - It seems that all svn properties may be iffy.

Resources

Very odd subversion issue

So, I had a file that refused to be checked in. Seems the file had previously been checked in, but then deleted with the TortoiseSVN checkbox "Keep Locks" checked. So it wouldn't go away. Anyway, the solution was svnadmin rmlocks /data/svn_repos/vhdl_bn /bn.bit

​http://paste.lisp.org/display/49343

​http://colabti.de/irclogger/irclogger_log/svn?date=2007-10-17,Wed;raw=on

(not really "trac" but I don't have a "svn" tag…)