savannah-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-users] SVN Syntax Question


From: Bob Proulx
Subject: Re: [Savannah-users] SVN Syntax Question
Date: Sat, 23 Apr 2016 16:33:40 -0600
User-agent: Mutt/1.5.24 (2015-08-30)

Stephen H. Dawson wrote:
> Thank you for the concise email.

I am laughing at this because I know most people will think I type in
way too much.  :-)

> I am glad we have this email list to discuss and learn for growing
> skills and developing valuable contributions.

Yes!  Please feel free to use the mailing list.  There are many good
people here with a lot of good experience with these things.

> as I do not have a test system to play and break and recover as part
> of the learning process.

You should be able to experiment on your current desktop.  Regardless
of what type of desktop operating system you have.  Subversion is
available for free (libre) GNU systems as well as for other non-free
ones.  You know the ones I mean without even mentioning them.  If you
have installed Subversion on your desktop then you should be able to
create local repositories and play with those there to gain
experience.  You mentioned "kernel" so I will assume you have a GNU
Unix-like system of some sort.  I will assume a GNU Unix-like system
here for the moment.  That is what I run and am most familar.  But if
say what type of system you have then there may be help from others
with specifics.

I create a test system on my machine like this.  I am doing all of
this as me.  I don't need root.  Let me emphasize that no root is
needed for any of this here.  Just be yourself.

  mkdir /tmp/svn-test
  svnadmin create /tmp/svn-test/foo-repos

That creates an empty repository.  It is in /tmp.  Note that normally
upon reboot /tmp is purged.  Don't store anything but truly temporary
things there as it will be gone after a reboot.  This makes it perfect
for throwaway play areas for short term use.  But if for any reason
you don't want to use /tmp then you can always use a directory in your
$HOME directory.  It is all the same.

After having created the repository then we need to set it up with the
trunk, branches, tags directories as is the normal convention.  We
create the repository with svnadmin but once created we access it with
the svn client command thereafter.  Operating on the repository using
the URLs needs a commit message and so I give it one -m "Msg" for the
command.  It is nice to do all three all at once.  This makes for one
long line.

  svn mkdir -m "Initialize repository" file:///tmp/svn-test/foo-repos/trunk 
file:///tmp/svn-test/foo-repos/branches  file:///tmp/svn-test/foo-repos/tags

Whew!  Long command.  But done.  Now we can check out trunk.

  svn checkout file:///tmp/svn-test/foo-repos/trunk /tmp/svn-test/foo
  cd /tmp/svn-test/foo
  svn info

Now we can generate some test files, check them in, and generally play
here.  It is all local files.  All will disappear on the next reboot!
So nothing long term.  All just a temporary scratch pad to play and
gain experience.

  date > file1.date
  svn add file1.date
    A         file1.date
  svn commit -m "Add a file"
  svn update

Always remember to update after a commit to sync your working copy
with the repository.  Otherwise it will be behind and 'svn log' will
not show the new revisions.  When that happens it is terribly
confusing!  I 'svn up' after every repository changing operation.  If
you want to test this you can for testing purposes NOT update and look
at the log first.  You won't see the last operation.  Then update and
you will see the last operation.

  svn commit -m "Add a file"
  svn log | less
  svn update
  svn log | less

If you ever get confusing results, 'svn up' and see if that
synchronizes things again.

This is a temporary play reporistory and local working copy.  Go play!
Everything is local.  Nothing goes anywhere.  Can't hurt anything.
Try out things.  Make branches.  Create a tag.  Don't save any
important work there as it is all temporary and will disappear from
/tmp at some point.  But great for testing.

Create a topic branch.

  svn copy -m "Create topic1 branch." file:///tmp/svn-test/foo-repos/trunk 
file:///tmp/svn-test/foo-repos/branches/topic1-branch
  svn log -v file:///tmp/svn-test/foo-repos/branches/topic1-branch | less
    ...verify all of the history is there...

That test case seems most like where you are with the project right
now.  Meaning that you can try scary operations at this point and see
how they turn out.  Such as what I suggested.  Which I agree feels a
little scary.  So best to test it in a test area to understand it.

  svn del -m "Prepare to swap trunk with topic1 branch." 
file:///tmp/svn-test/foo-repos/trunk

  svn move -m "Move topic1 branch to main trunk." 
file:///tmp/svn-test/foo-repos/branches/topic1-branch 
file:///tmp/svn-test/foo-repos/trunk

  svn log -v file:///tmp/svn-test/foo-repos/trunk | less
    ...verify all of the history is there...

If we are still sitting in our working copy which was trunk then we
can simply update.

  svn info
    ...verify where we are and what we are...
    URL: file:///tmp/svn-test/foo-repos/trunk
    Revision: 2
    ...revision 2 is behind revision 5 or whatever we are at now...
  svn update
  svn log -v | less
    ...verify all of the history is there...

Tagging is just a copy in the repository.  Using the URLs is typical
since normally we don't check out the entire repository.

  svn copy -m "Tag version 2.3." file:///tmp/svn-test/foo-repos/trunk 
file:///tmp/svn-test/foo-repos/tags/version-2.3

An observant person might realize that these are all simply files on
your local disk.  Which means you can make a backup snapshot of them
at any point.  You could set up a complicated situation and have five
different things you want to try.  Make a snapshot.  Then restore it
later to save all of that setup.  Makes testing things setup faster.
I won't say more but if this makes sense to you then go with it as it
is a handy feature.

Go play! :-)

> Furthermore, I am still not confident in my new kernel
> performance. I do not want to be juggling questions to know if SVN,
> my new kernel, or my lack of understanding is causing a barrier to
> achieve my goal when I am working on a production system such as our
> SVN system.

Subversion really has little to do with the kernel.  Subversion is
just a program like any other userspace program.  As long as your
kernel is not crashing, is seeming operating okay, then it almost
certainly is okay for doing all of these things.

I strongly encourage creating a test repository on your local system
and playing with it there.  Can't hurt anything there.  It is a great
way to learn how things work.

> I will svn copy the version 2.0 branch to trunk after svn delete of
> trunk. That will get us published for this weekend. We are already 2
> months in publishing behind due to my personal illness holding up our
> release efforts. Then, I can do the emailing of the release, breathe a
> bit, and then look deeper into the tagging activities you identify we
> should pursue. I agree with the benefits you have identified with
> tagging. I simply need to think about how to best tag, then plan, then
> test, then do the said tagging.
> 
> Again, thank you. I will be in touch in the future after I catch up from
> being behind in all activities cause by illness.

I am sorry to hear you were ill.  I am glad to hear that you are now
better.  Spend some time to stop and smell the roses along the way.
It is important not to spend too much time on the computer.  Get out
and enjoy the world outside.  :-)

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]