On Fri, Dec 20, 2019 at 07:19:27PM +0100, Dr. Thomas Orgis wrote:
> Please let's avoid the discussion whether one should version config
> files of the actual servers or the pupped/ansible/… scripts that
> generate them and just consider that
>
> 1. a directory tree on a live system is versioned in a Subversion
> repository,
> 2. various automated processes (package manager) modify that directory
> tree, and
> 3. Subversion is tripped up by nodes changing their kind from/to
> symbolic link, plain file, directory.
>
> I do have a script that looks at `svn st` and adds/removes files
> to turn ! into D, ? into A, basically. A mythical `svn synctree`
> command might do that, too, in a safer way.
There is a work-in-progress branch for such a feature:
https://svn.apache.org/viewvc/subversion/branches/addremove/
Would you be interested in working on this?
At present it doesn't implement much more than a wrapper around
'svn status' could do, mapping '!' to 'D' and '?' to 'A' status.
I intended to work on an ad-hoc rename detection feature for this
branch, like Git would do it. But I ran out of time.
Regardless, if this feature branch also solved the symlink issue you
describe below, the branch might already be worth merging to trunk.
> If a file in the working copy is replaced by a symlink, as
> reorganizations on Linux distribution upgrades make it happen, svn
> refuses the commit:
>
> svn: E145001: Commit failed (details follow):
> svn: E145001: Node '...' has unexpectedly changed kind
>
> Now, this can be worked around by moving the changed file/link aside,
> telling svn to forget about it, then move back and re-add. Commit. Like
> this example (out of one of the attached scripts that demonstrate the
> issue and resolution in some variations of changes in kind:
>
> # Known state to svn:
> echo a > a
> echo b > b
> svn add a b
> svn commit -m 'created two test files'
>
> # The set up:
> echo "The world happens and switches a for a symlink to b."
> rm a
> ln -s b a
Technically, SVN expects tree modifications to be made with
Subversion commands like 'svn add', 'svn rm' etc. Modifying
the working copy's tree structure with external commands is
actually somewhat "out of spec".
> This message of unexpected kind can be frustrating for the user that
> for sure can see that the erstwhile file is a symlink now and is
> wishing for a concise command that tells svn to just accept that fact.
I agree that it would be nice to make this case easier to deal with.
> (not too much thought on line breaks in file names). Of course it would
> be nice if there was the option to version ownership and permission
> info, too (not sure if extended attributes should be relevant for
> configuration). I faintly remember a project that built on svn to
> version whole filesystems including special/device files, but cannot
> find it right now.
Are you aware of 'asvn'?
https://svn.apache.org/viewvc/subversion/trunk/contrib/client-side/asvn?revision=1295006&view=markup
Received on 2019-12-20 19:36:49 CET