headers
kfogel | 21 Jul 2003 17:04
Favicon

New list 'users <at> subversion.tigris.org' created.

I've created a new mailing list, users <at> subversion.tigris.org, and
initialized it with the same subscribers as dev <at> .  (If your mailer
doesn't fold duplicate messages, then you'll get this mail twice.)

The purpose of the new list is to separate development discussion from
user support.  The dev list had been serving both audiences, but
lately has been getting so much traffic that people were getting
swamped.  In this thread...

http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=111898

...Justin Erenkrantz suggested it was finally time to split into two
lists (something we'd long been anticipating), and as near as I can
tell, everyone and their cousin followed up to agree with him :-).  So
now it's done.

If you want to unsubscribe from one of the lists, you can do so here:

   http://subversion.tigris.org/servlets/ProjectMailingListList

Those who remain subscribed to 'users', please keep an eye out for
threads that warrant developer attention.  Crossposting is fine when
the subject warrants it.  And, especially for these first few weeks,
let's all try to be extremely gentle when pointing out that someone
has posted to the wrong list :-).

Thanks,
-Karl

P.S. I'll be staying subscribed to 'users', and I hope other
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cedric Williams | 25 Jul 2003 21:52
Picon
Picon

Re: How to backup a running script? and how to recover out-of-sync file?

[cross-posted from users <at> ]

>>> jrepenning <at> collab.net 07/25/03 01:32PM >>>
>Well, I think I'd start by checking out a fresh, new working copy, 
>and see what sort of state it's in.  Then you can make your changes 
>as necessary.  The problems here seem to be limited to the particular 
>WC.
>
>But you've still got the more fundamental problem: it's not working 
>to "self-commit" a script if it has keywords to expand.  I don't 
>think that's going to go away.  Checking to see whether the file's 
>writable might be done, but it would only allow SVN to refuse the 
>checkin, which ain't necessarily what you had in mind!

Ok - I'm back in business. The trick was "fresh working copy." I checked out a new WC from the repository to
another directory. The daily.sh in the WC was the HEAD version of the script, but the .svn/text-base
version (of the new WC) matched the checksum that the 1st WC expected in the .svn/entries file. I copied
text-base/daily.sh.svn-base from the new WC to the same location in the old WC, and tried the commit.
Worked just fine.

=== Problem Recap
1 - I have a shell script that I use to back up a bunch of different working copies to my repository at the end of
the day
2 - This script had the $Id$ keyword tag embedded in a comment
3 - After setting svn propset svn:keywords "Id" on the script I called it to commit itself to the repository.
4 - svn committed the script to the repository (the new WC has the expanded $Id$ tag embedded)
5 - After the commit succeeded, svn changed the .svn/entries file to have the checksum information for the
checked-in version of the script (which has the $Id$ tag, though not expanded since the repository stores
the tag info in the props)
6 - Then svn tried to replace the current WC version with the repository version + expanded tag - **this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jack Repenning | 25 Jul 2003 23:08
Favicon
Gravatar

Re: How to backup a running script? and how to recover out-of-sync file?

At 2:52 PM -0500 7/25/03, Cedric Williams wrote:
>=== A Fix that Worked but will Probably Give Jack Heartburn

You got that right!  But I'm glad you're back in business.

>9 - check out a new WC in another location
>10 - copy the (repository version) file from .svn/text-base/ in the 
>new WC to the .svn/text-base in the old WC

Why not copy the changed file into the new WC, and check in and happy 
dance, without the unauthorized brain surgery on the text base?

>A - Should svn handle the move-previous-to-text-base before trying 
>to do keyword expansion (since that might fail)?

Well, that's not a "move-previous", in the context of commit, that's 
a "move-new": by the time the commit dust settles, the text base 
should be identical to the working file.  In particular for this 
case, it should have the new version of the keyword expansions.  So 
if we suppose it were to be made before keyword expansion, then we'd 
also have to suppose that the keyword expansion would be applied to 
it, independently--seems suboptimal.

>B - Should svn cleanup be able to recognize / handle the situation 
>when a checkin hasn't completed moving files around, and implement 
>(or suggest) some strategy to get the .svn directory back in shape?

Perhaps.  An RFE to that effect would certainly not be unreasonable.

>C - Attempting to obtain a write-lock on a file that will be updated
(Continue reading)

Permalink | Reply | 1 comment |

Gmane