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

RE: RE: file/dir checkout within subversion...

From: bruce <bedouglas_at_earthlink.net>
Date: 2004-08-25 17:14:18 CEST

geoff..

ok.. thanks for your response....

i can almost see where i could simply place the files in a single dir, and
simply let the user 'update' their working copy to match the state of the
repository... the issue with this approach is that the repository might grow
upwards of > 1000 files... which is simply too much for the user to have to
have this many files on their system, when they're only going to be dealing
with a small subset of the files... so i'm going to need to use multiple
dirs, with the requisite files.

that said, i have another question that i haven't found an answer to from
the docs...

can i essentially perform multiple checkouts for multiple directories within
my local workspace??? i assume that i can with no problem...

also, has anyone ever used eclipse with the subversion plugin? what are the
pros/cons/good/bad/etc...?? does the linux/windows version of
eclipse/subversion perform pretty much the same way...??

thanks for your comments/pointers/etc...

-bruce

-----Original Message-----
From: Geoff Krapf [mailto:geoffk@softartisans.com]
Sent: Wednesday, August 25, 2004 7:56 AM
To: bedouglas@earthlink.net; Ulrich Eckhardt;
users@subversion.tigris.org
Subject: RE: RE: file/dir checkout within subversion...

Yes, the expected workflow in Subversion would be:
 1. Checkout the working copy
 2. Update the working copy to match the repository
 3. Make changes
 4. Commit (Merge,resolve conflicts, etc)
 5. Repeat steps 2-4 forever

(Technically step 2 would not need to be done right after checking out
the WC because your WC is up to date :))

You can use the "svn status" command to show you what changes you've
made to your WC since you last updated. You can use "svn status -u" to
compare your WC to the repository and since you last updated. I use
status prior to every commit, etc.

Note that while checking out is directory based, commit can be file or
directory based; you only commit what you want to commit.

Wrt the granularity of security, if you're concerned about users being
able to modify other files then putting each file in a separate
directory may be a valid approach.

HTH!
-G.

-----Original Message-----
From: bruce [mailto:bedouglas@earthlink.net]
Sent: Wednesday, August 25, 2004 10:51 AM
To: Geoff Krapf; 'Ulrich Eckhardt'; users@subversion.tigris.org
Subject: RE: RE: file/dir checkout within subversion...

geoff...

thanks for the reply. i'm getting a better understanding of how
subversion handles some items/processes. but the issue that i was
raising with having to have a single file in a given directory is that
i'd like to be able to have a developer work on a single file at a time.

yeah, i know if a user checks out a directory, he could then simply work
on the single file, ignoring the others. however, he could also make
changes to the other files as well... as i understand subversion, when
used with apache, you can actually implement file/dir level access
privs. this would ultmiately allow me to determine who could access
which file. since subversion has no way to only check out a single file,
the kludge of having only one file per directory would allow me to
enforce the granularity i'm considering...

but geoff, you made the statement that one only has to check out a
directory once, and never needs to perform this process again. is this
because you would envision that the user would use the 'status/update'
functions to have the local working copy/area updated to reflect the
server's configuration???

thanks....

-bruce

-----Original Message-----
From: Geoff Krapf [mailto:geoffk@softartisans.com]
Sent: Wednesday, August 25, 2004 6:59 AM
To: bedouglas@earthlink.net; Ulrich Eckhardt;
users@subversion.tigris.org
Subject: RE: RE: file/dir checkout within subversion...

Bruce, since you're coming from VSS, I think you may be getting some
concepts confused.

In Subversion, a checkout is simply an action to create a working copy.
Unlike VSS, this does not provide any sort of locking or change the
state of the repository, it simply creates a local copy for you to work
in. You then work on that copy, and when you're ready to make your
changes, you commit them.

A commit is NOT the same as a VSS checkin, as there's no locking and
releasing of files. It takes the changes that you've made and sends
them to the repository, which then tells you if there's any conflicts
(i.e., someone committed to the working copy since you last updated your
working copy, and their changes conflict with yours). If there is a
conflict, you must resolve it yourself then commit again. Otherwise,
the commit will go through.

The regular pattern of working with Subversion is to do a checkout once,
and then work on that working copy. You can do multiple updates and
commits using that copy. You should very rarely need to perform another
checkout on the same code.

It would be slightly crazy to put one file per directory, simply so you
can checkout. Put them ina single directory in the repository, then
have your developers checkout that directory to create their local
working copy. When they want their changes to be put in the repository,
they should commit that file. They should not need to checkout ever
again. To get the latest files from the repository, they should run
"svn update", which is the equivelent of VSS's Get Latest.

I highly recommend carefully reading the SVN book
(http://svnbook.red-bean.com/), and probably reading TortoiseSVN's book
as well (http://tortoisesvn.tigris.org/docs/TortoiseSVN_en/index.html).
It outlines the concepts very well. Subversion is a very different
model of version control than VSS, but I think once you start using in
the way it's designed and not trying to map VSS work patterns over it,
you'll find that it's much cleaner and more powerful.

Hope that helps!

- Geoff

-----Original Message-----
From: bruce [mailto:bedouglas@earthlink.net]
Sent: Wednesday, August 25, 2004 6:47 AM
To: 'Ulrich Eckhardt'; users@subversion.tigris.org
Subject: RE: file/dir checkout within subversion...

ok...

to make sure i understand. the only way to really get a single 'working
file' is to have one file per directory, which would allow me to simply
checkout the dir containing the single file... is this what you're
saying regarding how subversion works...

thanks...

-bruce

-----Original Message-----
From: Ulrich Eckhardt [mailto:eckhardt@satorlaser.com]
Sent: Wednesday, August 25, 2004 3:24 AM
To: users@subversion.tigris.org
Subject: Re: file/dir checkout within subversion...

bruce wrote:
> the docs/searching through google implies that you can only
> 'check-out' a directory, and that you cannot checkout an individual
> file. is this correct? if i've misunderstood, can someone provide
> insight into how can you check out a single file???

You can retrieve a single file via 'svn cat URL'.
In order to create a working copy(something you work on and commit
changes from), svn needs to store its metadata somewhere and that is in
the .svn subdir. That is why you can't create a working copy of a single
file.

Uli

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Received on Wed Aug 25 17:11:50 2004

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