Re: control-M characters that are NOT end of line characters
On Wed, 04 Jan 2012, James Hartleroad wrote:
But I have a shell script removeCTLM.ksh that has an embedded cntl-m as
part of a regular expression, for example sed 's/^M//g' $file tmpfile
If this is a shell programming question rather than a subversion
question, then I suggest changing the script to not use an embedded
control-M. Here are two ways of doing that:
tr -d '\r' $infile $outfile
control_M=$(printf '\r')
sed -e s/${control_M}// $infile $outfile
--apb (Alan Barrett)
Re: how to compare an exported file (or set of files) against the repository?
On Wed, 05 Oct 2011, Konstantin Kolinko wrote: Can diff -u command take input from stdout? From stdin? Yes, in all diff implementations I have seen on unix-like systems. In answer to the original question, I suggest this approach: parse the output from svn log -q -r 1:HEAD $URL to get a list of revision numbers in which the URL was modified. For each such revision number, save the output from svn cat -r $REVISION $URL | diff -U3 - $FILE Find the smallest of those saved diff outputs, and it probably corresponds to the version that was originally checked out. --apb (Alan Barrett)
Re: how do I revert a bad commit without creating a new revision?
On Fri, 08 Jul 2011, Konstantin Kolinko wrote:
Another possibility: I think it is possible to effectively
truncate the repository by removing some files + running
svnadmin recover. Just theory - I have not tried it. I
wish there were official command (or instruction) how to
truncate a repository (as a cheap alternative to implementing
obliteration).
To truncate a repository that uses the fsfs format, so that
you lose everything after a certain revision, you can try the
following procedure. This is not supported, and might break
everything.
1. Ensure that no new changes can be committed. (Tell your
users to stop work, or rename the directory on the server to
make it inaccessible, or activate some hook scripts that deny
permission for any changes.)
2. Ensure that you have a backup.
3. Examine the db/current file in the repository. It should
contain the most recent revision number. If it's not what
you expected, then give up.
4. Change the db/current file, making it refer to the most
recent good revision (e.g. 417810) instead of to the newer
revisions that you want to disappear (e.g. 417811).
5. Delete the db/revs and db/revprops files corresponding to the
revisions that you want to disappear (e.g. db/revs/417/417811
and db/revprops/417/417811).
6. Allow access to the repository again.
Any working copies that have references to the revisions that have
disappeared, will now be broken. You may be able to fix them via
svn update -r${LAST_GOOD_REVISION}, but in the worst case, your
users will have to delete the working copies and check them out
again.
--apb (Alan Barrett)
Re: how do I revert a bad commit without creating a new revision?
On Fri, 08 Jul 2011, Daniel Shahaf wrote:
You missed a step.
Without that step the procedure will result in corruption (data loss) at
an undetermined time in the future.
The last time I performed this sort of repository truncation
was with a fsfs repository format 5, db/format 3, without a
rep-cache.db (as created by svn version 1.5). I don't know what
else you have to do if you have db/format 4 with a rep-cache.db
(as created by svn version 1.6), but I imagine it's something like
using the sqlite3 command line client to delete from rep_cache
where revision ${last_good_revision};. Newer formats will
probably need different treatment. Again, this is all unsupported
and at your own risk.
--apb (Alan Barrett)
[original message repeated for reference:]
To truncate a repository that uses the fsfs format, so that you
lose everything after a certain revision, you can try the following
procedure. This is not supported, and might break everything.
1. Ensure that no new changes can be committed. (Tell your
users to stop work, or rename the directory on the server to
make it inaccessible, or activate some hook scripts that deny
permission for any changes.)
2. Ensure that you have a backup.
3. Examine the db/current file in the repository. It should
contain the most recent revision number. If it's not what
you expected, then give up.
4. Change the db/current file, making it refer to the most
recent good revision (e.g. 417810) instead of to the newer
revisions that you want to disappear (e.g. 417811).
5. Delete the db/revs and db/revprops files corresponding to the
revisions that you want to disappear (e.g. db/revs/417/417811
and db/revprops/417/417811).
6. Allow access to the repository again.
Any working copies that have references to the revisions that have
disappeared, will now be broken. You may be able to fix them via
svn update -r${LAST_GOOD_REVISION}, but in the worst case, your
users will have to delete the working copies and check them out
again.
--apb (Alan Barrett)
--no-config-dir option?
Is there a way to prevent svn from creating a $HOME/.subversion directory? I know how to make it put the directory in a different location using --config-dir=/wherever, but I want to avoid creating it entirely. I can't find an option like --no-config-dir or --config-dir=none. I have discovered an ugly workaround: If I set --configdir=/nonexistent/nonexistent (giving the name of a directory that does not exist, and whose parent also does not exist), then the absence of the parent directory means that svn will be unable to create the child directory. --apb (Alan Barrett)
Re: --no-config-dir option?
On Thu, 23 Dec 2010, Stefan Sperling wrote: I don't think there is an official way to prevent the config dir from being created. I'd be interested to know why you need this. What is your use case? The event that made me notice the problem was cron job owned by root, whose command was something like su serviceuser -c 'svn update /path/to/dir'. Think of updating a working copy that contains the files used by a web server. The svn update command runs in a context where $HOME is root's home directory, and serviceuser is not even allowed to write there, and might not even be allowed to read, so I got an error or warning (I forget which, and the details change according to the permissions). You ask why I need to avoid creating a .subversion directory, and I suppose that I don't absolutely need to avoid creating it, but I also don't need *to* create it (it won't contain any useful information), and I don't want the clutter. Another annoying issue is that commands that one would expect to be read-only (such as svn status or svn info) also create the config directory. --apb (Alan Barrett)
Re: svn Farm
On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote: What he really wants is an alternate-universe Subversion which never had the plaintext password storage feature in the first place. I'd settle for being able to block that local use on the server side: OK, so you want a feature in which the client reports to the server here are some important aspects of my configuration, and the server replies I don't like this aspect of your configuration, so I refuse to work with you. I suggest that you write up a proposal for such a feature, or begin a focused discussion about how such a feature could work and could be useful. --apb (Alan Barrett)
Re: Subversion Blues - please help
On 9/29/2010 11:11 AM, Alan Barrett wrote: I make my hooks directory a working copy of an appropriate subdirecrory in the repository (or in another repository), and use a post-commit hook to run svn update in the hooks dir when it sees a commit to the relevant path. Les Mikesell wrote on Wed, Sep 29, 2010 at 11:25:27 -0500: Does that cause trouble when the post-commit script itself is updated while running - or does svn always write new files and rename when complete which should at least work on unix-like systems? On Thu, 30 Sep 2010, Daniel Shahaf wrote: I'm pretty sure we don't let you end up with a half-written file in the working copy. But let's hope the 'svn update' never runs into a conflict, or things are going to get interesting Yes, things could get nasty if there are conflicts, but that won't heppen if you are careful not to leave uncommitted changes lying around the hooks directory. The only problems that I have encountered have been when I edit in the hooks directory itself (instead of in a separate working copy), run svn commit, and then have the post-commit hook try to run svn update while the directory is still locked by the outer svn commit process. This causes the inner svn update to fail, with harmless error messages. --apb (Alan Barrett)
Re: Subversion Blues - please help
On Tue, 28 Sep 2010, Les Mikesell wrote: It would have made sense to me to have the config/scripts versioned but I've forgotten how that worked in CVS and I'm too lazy to look it up. And I suppose it would be hard to change now in a backwards-compatible way since svn doesn't keep the head version as a normal file like cvs/rcs. I make my hooks directory a working copy of an appropriate subdirecrory in the repository (or in another repository), and use a post-commit hook to run svn update in the hooks dir when it sees a commit to the relevant path. --apb (Alan Barrett)
Re: svn diff working copy against a different branch
[replying to an old mesage] On Thu, 05 Aug 2010, Arpad Ilia wrote: Is it possible to diff a working copy against code in another branch (trunk in this case)? Or is it expected to checkout trunk and use a diff utility every time? As far as I know you can only diff two working copies or two URLs (if one of the arguments is an URL then both will handled as such). If you use svn diff with the --old and --new options, then you can make one of them point to the URL for a different branch, and the other point to a working copy. svn diff --old=svn://server/repo/branch/subdir --new=./subdir --apb (Alan Barrett)
