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

Re: Checking out individual files

From: Bob Proulx <bob_at_proulx.com>
Date: 2007-01-28 01:27:23 CET

Eric wrote:
> With Subversion, you can check out whole repositories, and you can
> check out individual directories within the repository ... but you
> (apparently) can't check out individual files within a directory.

Generally yes that is true. But it is also true that in some
circumstances you *can* check out individual files. This is by using
the properties of mixed revision working copies.

> I'm told that this was a design decision made by the Subversion architects.
>
> My question was ... What was the reasoning behind this decision?

I was not involved but I can see how it would be a result of the way
the .svn directory includes information about the files. Personally I
much prefer having self contained directories with data and meta-data
together than alternative systems which keep meta-data separate. This
is after long personal experience with two such systems that use
external meta-data. I think they made the right choice. (However
having each directory have an individual .svn with recorded directory
data has been a source of confusion for some users when they move them
around outside of svn commands.)

> If you can check out a subdirectory within a repository without
> having to check out the whole repository, why not also then be able
> to check out an individual file within a subdirectory?

Often the topic comes up of how to check out a single file in
subversion. This can be done, depending upon the history. It depends
upon having a point in the history of the project when the directory
has been committed but it is empty of files. This is frequently true
in the standard directory layout of branches, tags, trunk if that is
committed by itself as a first commit.

At that point in the history the directory was empty. The current
directory version is at r1 and no files are present. Now let's update
a single file.

  svn update a_single_file

This is a fully modifiable working copy. The 'svn status' will be
happy with it. 'svn status -v' will show it to be a mixed revision
working copy. This is just like after a commit where the file
committed is later than the other files. It can be modified. The
normal 'svn status' and 'svn diff' commands will work. You can run
'svn commit' and everything is happy. Effectively only a single file
was checked out.

  editor a_single_file
  svn commit
  svn update -r1
  svn update another_single_file
  editor another_single_file
  svn commit

This does not work however if there is no time in the history when
that file was empty. If a directory was imported and committed with
both the directory and the files in the same commit then it will not
be possible to get back to a point time when the directory was empty.
At no point in the project history will the directory be empty.

Because most projects do follow the recommended directory layout it
is usually possible to check out a single file. I hope this technique
may be of help to you.

Here is the entire process in a way that you can demonstrate the steps
from start to finish.

  svnadmin create svn_repos
  URL=file://$PWD/svn_repos
  svn mkdir $URL/branches $URL/tags $URL/trunk -m "Creating infrastructure."
  svn checkout $URL/trunk adir
  cd adir
  svn info
  date -R > foo
  svn add foo
  svn commit -m "foo: New file."
  date -R > bar
  svn add bar
  svn commit -m "bar: New file."
  svn update -r1
  svn update foo
  echo updating foo >> foo
  svn commit -m "foo: updated"
  svn update -r1
  svn update bar
  echo updating bar >> bar
  svn commit -m "bar: updated"

Hope this helps!

Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jan 28 01:28:01 2007

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

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