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

Re: Very esoteric problem

From: Toby Johnson <toby_at_etjohnson.us>
Date: 2004-06-30 17:02:03 CEST

Campbell, Matthew A wrote:

>I've got to admit, this approach (keeping the entire repository more-or-less
>permanently checked-out) never occured to me.
Yes, that is a little weird to get used to at first, especially for
those like me who are used to working with a locking model like Visual

>>1. Do an "svn list --recursive" of /trunk to get a list of
>>every file in
>>the repository
>>2. grep this list for interesting files
>>3. checkout only those files
>>4. run your update tool
>>5. do an update.
>This intrigues me, specifically #3, since my previous experiences lead me to
>believe this step cannot be done (at least without non-trivial coding using
>the bindings). Also, did you perhaps mean #5 to say "do a commit" rather
>than "do an update"?
I'm sorry, I typed too fast: you can't just check out a single file; you
would need to check out that whole directory. There is a
"--non-recursive" option to checkout available, although as has been
mentioned on this list recently, that command has issues where it b0rks
your working copy in that recursive updates are no longer possible (see
http://subversion.tigris.org/issues/show_bug.cgi?id=695). However, for
your needs, that shouldn't really matter, since you're only interested
in updating that one file anyway.

Of course, if these config files are in their own directory, or in a
directory that doesn't have many files or subdirs, it's no big deal to
check out just the parent directory of each config file, update the
file, then commit (yes, I meant commit, not update before) those files.
The downside to this approach (checking out lots of little working
copies instead of one big working copy) is that you will also have one
commit for each config file instead of one big fat atomic commit for all
of them, but CVS users have been living with that for years. :)

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 30 17:20:41 2004

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.