[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

An attempt to use subversion

From: Sam TH <sam_at_uchicago.edu>
Date: 2001-04-17 17:40:31 CEST

Well, having gotten the "create a repository" situation under control,
thanks to Kevin and Ben, I decided to give subversion a test.
Figuring that there was no better subject for testing with pre-alpha
software than my homework, I proceeded to check in a directory of
about 20 files and one subdir with another 20 into a newly created
repository:

[sam_at_samth cs-compile]$ export REPOS=file:///home/sam/repos/
[sam@samth cs-compile]$ svn import $REPOS old-flame/ flame

Now, from the interface of import, and my experience with CVS, I would
expect this to do one of the two following things:

1. Create a dir in the repository called old-flame, with an inital tag
of flame and the contents of old-flame.
2. Create a dir in the repository called flame, the contents of
old-flame.

But, this command produces lots of messages like so:

[snip]
Adding old-flame//flame/tests/identifier.exp
Adding old-flame//flame/tests/keywords.exp
Adding old-flame//flame/tests/numbers.exp
Adding old-flame//flame/tests/quick.exp
[snip]

This suggests that a directory in the repository is being created,
called old-flame, with a subdir called flame, with that subdir having
the contents of old-flame. That seems really strange and
counter-intuitive. Fortunately, that isn't what actually happens, as
we soon see.

Then, I prepare to check out my imported directory. I do this as
follows:
[sam_at_samth cs-compile]$ svn co file:///home/sam/repos/flame -d flame

This does the right thing, and creates a directory called flame, with
the contents that were in old-flame. So it seems that the world makes
sense again. And the messages are clearer too, looking like so:

A flame/plex.pyc
A flame/pyson.pyc
A flame/flameparse.py
A flame/read1.flm
A flame/bigexpr.flm

Then, we try something else:

[sam@samth flame]$ svn rm profdata
[sam@samth flame]$ svn ci
Deleting ./profdata
Commit succeeded.

So far so good. Then

[sam@samth flame]$ svn up
D ./profdata

and
[sam@samth flame]$ svn rm pyson.pyc
[sam@samth flame]$ svn up
[sam@samth flame]$

This is confusing again - running svn up gives me no indication that
anything has changed [1]. But running svn up *after* the commit tells
me that I changed something. Seems backwards.

Then we try something more complex -

[sam@samth flame]$ svn rm CVS/ ( this used to be in cvs )
[sam@samth flame]$

Nothing happens. There is no evidence (either from output, or from
the files in the SVN dirs) that this command did anything at all.

Then we try

[sam@samth flame]$ rm -rf CVS/
[sam@samth flame]$ svn rm CVS

apr_error: #2, src_err 0 : No such file or directory
  CVS/SVN/entries
[sam@samth flame]$ svn up

apr_error: #2, src_err 0 : No such file or directory
  ./CVS/SVN/entries
[sam@samth flame]$

So now, not only is it not gone from the repository, but my wc won't
update any more. Oops.

Ok, that's it for now. I'll check out another wc later, and let you
know how it goes from there.

[1] I remember the long dicussion about using "cvs up" for this
purpose a while back. I don't remember the exact conclusion, but I
think that svn up should say something here. And it certainly should
if it's going to say something *after* the commit.
           
sam th --- sam_at_uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dyndns.org/decss

  • application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:28 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.