Nabble - Subversion

Re: bug candidate: replacing symlink with other symlink turns to plain file on merge

2008-09-05T21:28:37Z

Karl Fogel <kfogel@...> writes:
> So, turns out the problem is not in the merge at all, but in the second
> commit -- it never tacks on the "svn:special" property at all, even
> though a symbolic link is being committed. Run this repro script and
> the problem will be obvious:

Btw, note that the property is still present locally. IOW, working copy
and repository are out of sync afterwards :-). Nice, huh?

I've added the appropriate comments to issue #3282 and assigned it to
myself.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

From forum: Subversion Dev

[Issue 3282] commit replacing symlink with other symlink results in plain file in repository

2008-09-05T21:23:57Z

http://subversion.tigris.org/issues/show_bug.cgi?id=3282

User kfogel changed the following:

What |Old value |New value
================================================================================
Status|NEW |STARTED
--------------------------------------------------------------------------------
Summary| replacing symlink with ot|commit replacing symlink w
|her symlink results in pla|ith other symlink results
|in file on merge |in plain file in repositor
| |y
--------------------------------------------------------------------------------

------- Additional comments from kfogel@... Fri Sep 5 21:23:57 -0700 2008 -------
I've resummarized this issue, now that we know where the problem really happens.
It's in the commit, the one that replaces the old symlink with the new one of
the same name -- the "svn:special" property never gets tacked on, although the
file remains a symlink in the working copy after the commit, of course.

I just posted to the thread about this, giving a repro script. Here's a
slightly improved version of that script, demonstrating that after the r3
commit, the "svn:special" property is present locally but *not* in the
repository. (How's that for corruption? Assigning to self.)

-----------------------------------------------------------------------
#!/bin/sh

SVN=`which svn`
SVNADMIN=`which svnadmin`

URL=file:///`pwd`/repos

rm -rf repos wc

${SVNADMIN} create repos
${SVN} co ${URL}/ wc

cd wc

# Add two regular files in r1.
touch foo bar
${SVN} add foo bar
${SVN} ci -m "Add regular files foo, bar."
${SVN} up

# Add a symbolic link to foo in r2.
ln -s foo link
${SVN} add link
${SVN} ci -m "Add symbolic link to foo."
${SVN} up

# Change it to a symbolic link to bar in r3.
${SVN} rm link
ln -s bar link
${SVN} add link
${SVN} ci -m "Changed symbolic link to bar."
${SVN} up
echo ""
echo "### Locally, the file has the svn:special prop after the r3 commit."
echo "### Running 'svn plist -v link':"
echo ""
${SVN} plist -v link
echo ""
LINK_URL=`${SVN} info link | grep "URL: " | cut -d " " -f2`
echo "### But the svn:special prop didn't go into the repository in r3!"
echo "### Running 'svn plist -v ${LINK_URL}':"
echo ""
${SVN} plist -v ${LINK_URL}
echo ""
echo "### No output. Hmmm. Note that the property did make it into r2..."
echo "### Running 'svn plist -v ${LINK_URL}@2':"
echo ""
${SVN} plist -v ${LINK_URL}@2
echo ""
echo "### So the problem is with the replacing commit, not with the merge."

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@...
For additional commands, e-mail: issues-help@...

From forum: subversion - issues

[Issue 3282] commit replacing symlink with other symlink results in plain file in repository

2008-09-05T21:23:57Z

From forum: Subversion Dev

Re: bug candidate: replacing symlink with other symlink turns to plain file on merge

2008-09-05T21:15:16Z

"David Glasser" <glasser@...> writes:
> On Fri, Sep 5, 2008 at 3:50 PM, Karl Fogel <kfogel@...> wrote:
>> Wait, I think I've got it!
>>
>> The problem is that the "svn:special" property is set to "link" on both
>> the old and new file, so it never appears as a prop diff -- nor should
>> it, since there's no difference.
>
> Really? I'd expect that for a 'R'eplaced file, property diffs should
> be based against the empty file, not against the deleted file.

(Bonus points to whoever supplies the appropriate Big Lebowski quote to
go along with the following...)

So, turns out the problem is not in the merge at all, but in the second
commit -- it never tacks on the "svn:special" property at all, even
though a symbolic link is being committed. Run this repro script and
the problem will be obvious:

--------------------------------------------------------------------------
#!/bin/sh

SVN=`which svn`
SVNADMIN=`which svnadmin`

URL=file:///`pwd`/repos

rm -rf repos wc

${SVNADMIN} create repos
${SVN} co ${URL}/ wc

cd wc

# Add two regular files in r1.
touch foo bar
${SVN} add foo bar
${SVN} ci -m "Add regular files foo, bar."
${SVN} up

# Add a symbolic link to foo in r2.
ln -s foo link
${SVN} add link
${SVN} ci -m "Add symbolic link to foo."
${SVN} up

# Change it to a symbolic link to bar in r3.
${SVN} rm link
ln -s bar link
${SVN} add link
${SVN} ci -m "Changed symbolic link to bar."
${SVN} up
LINK_URL=`${SVN} info link | grep "URL: " | cut -d " " -f2`
echo ""
echo "### But the svn:special prop didn't go into the repository in r3!"
echo "### Running 'svn plist -v ${LINK_URL}':"
echo ""
${SVN} plist -v ${LINK_URL}
echo ""
echo "### No output. Hmmm. Note that the property did make it into r2..."
echo "### Running 'svn plist -v ${LINK_URL}@2':"
echo ""
${SVN} plist -v ${LINK_URL}@2
echo ""
echo "### So the problem is with the replacing commit, not with the merge."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

From forum: Subversion Dev

Re: How to print out only the most recent log message for each file in a project?

2008-09-05T20:52:57Z

>> If I do 'svn log HEAD', I only get the log message for the most

>> recent
>> commit. I'd like something like an option to 'svn status' that
>> prints log
>> messages, but it doesn't seem to exist. Is it possible to do what I
>> want?
>
> Revisions are global to the repository, not unique to each file. So,
> to get the log message associated with the revision where each file
> was last changed, you'll need to script:
>
> For each file, run svn info
> Parse the output to get the last changed rev
> Run svn log -r <rev> <filename>
>
> Or something close to that.

Something close to what you want it possible. Printing the log
statements for individual files and directories is likely to be nigh
unto unintelligible. However, `svn list --verbose URL` will print the
last revision, last modifier, modify date, and path for every node at
the specified URL. This is certainly much easier than scripting a
solution and dealing with the network latency and extra parsing.

That said, it might be nice to have finer control over what is
printed, but the predictable structure of --verbose is easy enough to
handle, and there are many more important fish to fry.

If you really want the log messages, I'd recommend getting the verbose
list, creating a non-repeating set of revision numbers, then running
`svn log --revision REV` for each revision. Or use something like
WebSVN or ViewVC to browse to the revisions of interest. :-)

- Quinn

smime.p7s (3K) Download Attachment

From forum: Subversion Users

Re: Diff Question.

2008-09-05T18:05:31Z

Hi Ryan (and everyone else of course)

I have tried the following, but it still returns the entire file as
being different, is there something obvious I am missing?

svn diff /svn/trunk/project/filename.cfm -r head:2136 -x --ignore-eol-
style -x -w

I even tried using the repository instead of the local WC, but it
returned the same.

svn diff http://192.168.10.95/svn/trunk/project/filename.cfm -r head:
2136 -x --ignore-eol-style -x -w

Index: filename.cfm
===================================================================
--- filename.cfm (revision 3885)
+++ filename.cfm (revision 2136)
@@ -1,710 +1,726 @@

Gavin.

It's always darkest before the dawn. So if you're going to steal your
neighbour's paper - then that's the time to do it.

On 06/09/2008, at 10:27 AM, Ryan Schmidt wrote:

>
> On Sep 5, 2008, at 12:40 AM, Gavin 'Beau' Baumanis wrote:
>
>> I was just wondering how others coped when trying to compare two
>> revisions of a file, but diff (whether it be a GUI-tool or "svn
>> diff" shows the entire document as being 1 big difference?
>
> And why does the diff tool do that?
>
> One reason is differing line endings. If so, then convert the one
> version of the document to the same line ending style as the other
> version and compare again.
>
> Or you can use the "ignore whitespace" option to diff.
>
> If your files differ on every line for a reason other than
> whitespace, please explain.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

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

From forum: Subversion Users

Re: svn: Expected version '3' of repository; found version '5'

2008-09-05T17:57:32Z

On Sep 4, 2008, at 2:48 AM, Rajeev Jain wrote:

> I am using subversion 1.4.6 version on
> CentOS 4.3.
> I have a script for backup purpose.
> When I run it directly on command prompt,it works.
> But when I run it using cron, it gives some errors.
> I am mentioning error below:
>
> svn: Expected version '3' of repository; found version '5'

It sounds like the version of Subversion that's getting run from cron
is an older version than the one that's getting used when you run it
at the command prompt. Perhaps your PATH variable is different in
cron than it is at your usual command prompt.

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

From forum: Subversion Users

Re: bug candidate: replacing symlink with other symlink turns to plain file on merge

2008-09-05T17:55:34Z

On Fri, Sep 5, 2008 at 3:50 PM, Karl Fogel <kfogel@...> wrote:
> [originally misposted in the wrong thread]
>
> Wait, I think I've got it!
>
> The problem is that the "svn:special" property is set to "link" on both
> the old and new file, so it never appears as a prop diff -- nor should
> it, since there's no difference.

Really? I'd expect that for a 'R'eplaced file, property diffs should
be based against the empty file, not against the deleted file.

--dave

> But (I think) the code that handles the "svn:special" property only gets
> activated when the property is added or removed. (I guess it would also
> get activated if the property value changed, but in practice, it's
> always "link" right now, since the details appear in the file text.
> Thus our concern here is with the property being added or removed.)
>
> I haven't investigated this line of reasoning yet, but will later
> tonight if no one beats me to it.
>
> -Karl
>
> Karl Fogel <kfogel@...> writes:
>> BUCHMULLER Norbert <norbi@...> writes:
>>> I found a bug in Subversion. Can someone pls test it on the latest
>>> version? (Or tell me if it's a known bug that I overlooked.)
>>>
>>> If a symlink is replaced by a different symlink (svn rm link; ln -s foo
>>> link; svn add link; svn ci), everything goes fine, up to the point when
>>> you try to merge this change to a branch, as on the merge the element
>>> becomes a plain file (instead of a symlink).
>>>
>>> Note that this bug is similar to issue 2064, but is not the same. (Issue
>>> 2064 is about the merge of a change creating a new symlink, this one is
>>> about the merge of a change that replaces a symlink with a different one.
>>> Just to be sure, I tested that it is not a regression of 2064.)
>>>
>>> Note2: I understand that replacing an element this way is silly (it
>>> creates a new element with the same name but separate version history).
>>>
>>> See the attachment (rm_symlink+add_symlink+merge.sh) for a recipe how to
>>> reproduce the bug.
>>
>> Thank you for the excellent reproduction script. I can also reproduce
>> the bug, using your script.
>>
>> When I traced in with GDB, I set breakpoints on svn_client_merge_peg3(),
>> and on each of the merge_callbacks in libsvn_client/merge.c:
>>
>> /* The main callback table for 'svn merge'. */
>> static const svn_wc_diff_callbacks3_t
>> merge_callbacks =
>> {
>> merge_file_changed,
>> merge_file_added,
>> merge_file_deleted,
>> merge_dir_added,
>> merge_dir_deleted,
>> merge_props_changed,
>> merge_dir_opened,
>> merge_dir_closed
>> };
>>
>> Here's what I found:
>>
>> Breakpoint 11, svn_client_merge_peg3
>> (source=0x9b0f5e0 "", ranges_to_merge=0x9b0db18,
>> peg_revision=0xbfa635d8, target_wcpath=0x806fff8 "",
>> depth=svn_depth_unknown, ignore_ancestry=0, force=0, record_only=0,
>> dry_run=0, merge_options=0x0, ctx=0x9b0e338, pool=0x9b0d990) at
>> subversion/libsvn_client/merge.c:6569
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 5, merge_file_deleted
>> (adm_access=0x9b0f710, state=0xbfa62d4c, mine=0x9bb2710 "link",
>> older=0x9bb2810 "/tmp/tmp", yours=0x9b75f68
>> ".svn/tmp/tempfile.tmp", mimetype1=0x0, mimetype2=0x0,
>> original_props=0x9bc1348, baton=0xbfa63428) at
>> subversion/libsvn_client/merge.c:1062
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 4, merge_file_added
>> (adm_access=0x9b0f710, content_state=0xbfa62d5c,
>> prop_state=0xbfa62d58, mine=0x9bc20e8 "link", older=0x9b75f68
>> ".svn/tmp/tempfile.tmp", yours=0x9bc2380 ".svn/tmp/tempfile.2.tmp",
>> rev1=0, rev2=3, mimetype1=0x0, mimetype2=0x0,
>> prop_changes=0x9bc20f0, original_props=0x9b75e18, baton=0xbfa63428)
>> at subversion/libsvn_client/merge.c:821
>> (gdb) c
>> Continuing.
>> --- Merging r3 into '.':
>> R link
>>
>> Hmmm, at this point, 'link' on disk is not a symlink. The "svn:special"
>> prop (needed to turn it into a symlink) was not delivered via
>> prop_changes and original_props (I stepped through earlier to make
>> sure). Then later we hit this:
>>
>> Breakpoint 10, merge_props_changed
>> (adm_access=0x9b0f710, state=0xbfa62ef4, path=0x9b8c6c8 "",
>> propchanges=0x9b8c6a8, original_props=0x9b927d0, baton=0xbfa63428)
>> at subversion/libsvn_client/merge.c:536
>>
>> ...However, when I step through, it just sets some svn:entry props. It
>> still didn't supply svn:special. After that, we don't hit any merge
>> callbacks (except for merge_dir_closed(), I think).
>>
>> I haven't traced the problem to its source yet, but I'm posting this in
>> hopes of saving you or someone else some time, if you decide to try
>> debugging it.
>>
>> -Karl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
David Glasser | glasser@... | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

From forum: Subversion Dev

Re: Commit failed: Can't create directory

2008-09-05T17:54:54Z

On Sep 4, 2008, at 10:02 AM, Joel Harris wrote:

> I started getting this error all of a sudden:
>
> Commit failed (details follow):
> Can't create directory
> 'C:\SVNRepositories\asp\ThatsLife\db\transactions\178-1.txn': The
> system cannot
> find the path specified.
>
> I've looked through the backups of my repository folder and none of
> them contain a folder called db\transactions. Of course the db
> folder exists, but not the transactions folder. I tried checking
> out the project anew and committing changes and I get the same
> error. Please advise.

Create the transactions folder.

I recall other postings here before and the folder having been
renamed. Did you recently change the version of Subversion you were
using, or start using a different client based on a different version
of the Subversion libraries?

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

From forum: Subversion Users

Re: svn log improvement proposals

2008-09-05T17:45:03Z

Eirik Bjørsnøs wrote:

> Hi,
>
> I recently mentioned[1] some issues I was facing adding merge tracking
> features to my version control history search tool [2].
>
> Having spent the last few days doing some actual work on this feature,
> I have run into some issues with the Subversion log APIs/protocols.
>
> Using the current API there's no way for me to specify the exact kind
> and amount of information I want from svn log.
>
> Specifically, here are the issues I'm facing:
>
> A) Can't specify depth of include-merged-revisions (-g)
>
> If a merged revision also has a merged revision it will be included in
> the log. (And that revision can again be a merge of a merge of a merge
> many levels down..) Since I look at the repository log as a whole, it
> doesn't make sense to log merged revisions more than one level deep.
> Any information about "nested" merges will have appeared earlier in
> the log.
>
> The following thread discusses a --depth parameter, but I can't seem
> to find it leading to any conclusion:
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=661083
>
> Proposal: Add a --depth switch to svn log (and the protocols, simple
> client filtering won't be very useful).
>
> B) Can't limit information returned specifically about merged revisions.
>
> The -v option currently applies to merged revisions as well as the
> "actual" revisions. I need full information about the actual
> revisions, but for merged revisions I only need the number of the
> revision. Everything else I already have cached.
>
> For my specific use case a special "--just-revision-for-merged" would
> be ok. However, for consistency it's probably better to add versions
> of --verbose, --with-all-revprops and --with-revprop that apply
> specifically to merged revisions.
>
> Proposal: Add merge-specific versions of --verbose,
> --with-all-revprops and --with-revprop.

I wonder if the following idea would help in these cases. In the repository
layer, instead of returning the complete depth of the merged revisions, just
return the ranges (if requested), this would allow the client contacting the
repo to make repeated requests if "deep" merge information was desired, or
selectively request additional information about merged revisions of interest.

The above change has been discussed before, but I don't think anybody has made
any progress on it. The idea is pretty straightforward, but the implementation
will be by no means trivial. It would require a bit of on-list discussion to
hammer out the semantics of the APIs.

Eirik, does this sounds like something you can look into?

-Hyrum

signature.asc (265 bytes) Download Attachment

From forum: Subversion Dev

Re: svn commit still holds locks when server-side post-commit runs

2008-09-05T17:44:25Z

On Sep 5, 2008, at 12:34 PM, Markus Kuhn wrote:

> Ryan Schmidt wrote on 2008-09-04 21:12 UTC:
>
>> Well, no output from a post-commit hook is ever sent to a Subversion
>> client.
>
> If the post-commit hook exits with a non-zero return value, its stderr
> output will be forwarded to, and displayed by, the client.

Oops -- I didn't know that. I tested with 1.5.2 and you're right. I
was mistaken. Thanks for pointing this out.

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

From forum: Subversion Users

Re: About pre-revprop-change

2008-09-05T17:37:01Z

On Sep 5, 2008, at 1:48 PM, eg wrote:

> watanabe@... wrote:
>
>> I'm a biginner of SVN in Japan, I want to change the past log-
>> message, but I got an error from SVN like 'Ask your administrator
>> to create the hook of pre-revprop-change'. But there is no
>> information about it in my manual and I have no idea about the
>> administrator it's mentioned.
>> Could someone teach me the way to change the log message or change
>> past log-message ?
>
> It is also on the Subversion FAQ
> see:
>
> http://subversion.tigris.org/faq.html#change-log-msg

It is also provided for you in the script pre-revprop-change.tmpl in
the hooks directory of your repository. This is an example script
designed to show you how to write a pre-revprop-change hook, and the
example given happens to be how to allow log messages to be changed.
Simply copy the file pre-revprop-change.tmpl to pre-revprop.change
(without an extension) and give the script the execute bit (for
example with "chmod 755 pre-revprop-change") and that should be all.
You may want to read the script too to see how it was done.

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

From forum: Subversion Users

Re: On commit, svn server to change line ending to unix style for .sh files.

2008-09-05T17:33:41Z

On Sep 5, 2008, at 6:57 PM, Fu-Tung Cheng wrote:

> On Fri, 9/5/08, Larry Shatzer, Jr. wrote:
>
>> Now please read
>> http://svnbook.red-bean.com/nightly/en/
>> svn.advanced.props.html#svn.advanced.props.auto
>>
>> And you should read
>> http://subversion.tigris.org/faq.html#auto-props
>
> The information appears somewhat contradictory though. The first
> link implies that I can set enable-auto-props and that I can choose
> to have it set the eol-style to LF for .sh files.

Correct: you do that on the client.

> The second link says there is no server mechanism. Did I mis-
> interpret something?

Correct: there is no server-side mechanism to modify the properties
automatically; this only exists on the client side. On the server you
cannot change the data the user submitted in the commit; you can
merely reject a commit if its contents is not satisfactory for
whatever reasons you define.

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

From forum: Subversion Users

Re: On commit, svn server to change line ending to unix style for .sh files.

2008-09-05T17:32:13Z

On Sep 5, 2008, at 12:54 PM, Fu-Tung Cheng wrote:

> The scenario I have is that I always want .sh files - any other
> files - to have the unix eol style but I never want to have to set
> them. svn should be smart enough or configurable enough to set
> this without any interaction from my or any other clients behalf.
>
> So the question remains, is this feature on the roadmap? Why
> should everytime I want to add a new .sh file to the repository I
> need to manually set the eol:style to CR when the server could say
> "hey that's a .sh file I know what style he wants and just set it".
>
> I realize that adding files doesn't occur all the time and that
> some client allow you to select a bunch of files and set all their
> eol:style at once but this is still error prone and much less nice
> than an automated server side setting.

Note: it's "svn:eol-style", not "eol:style", and you want to set it
to LF (Unix- and Mac OS X-style line endings), not CR (old Mac-style
line endings).

There is no server-side mechanism to set these properties for you.
The best you can do is to set up your clients properly, and install a
pre-commit hook to reject any commit that does not meet your
requirements. In the error message that such a hook prints, you can
inform the user how to set up their client properly.

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

From forum: Subversion Users

Re: Diff Question.

2008-09-05T17:27:26Z

On Sep 5, 2008, at 12:40 AM, Gavin 'Beau' Baumanis wrote:

> I was just wondering how others coped when trying to compare two
> revisions of a file, but diff (whether it be a GUI-tool or "svn
> diff" shows the entire document as being 1 big difference?

And why does the diff tool do that?

One reason is differing line endings. If so, then convert the one
version of the document to the same line ending style as the other
version and compare again.

Or you can use the "ignore whitespace" option to diff.

If your files differ on every line for a reason other than
whitespace, please explain.

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

From forum: Subversion Users

[Issue 3282] replacing symlink with other symlink results in plain file on merge

2008-09-05T17:15:39Z

http://subversion.tigris.org/issues/show_bug.cgi?id=3282

User stsp changed the following:

What |Old value |New value
================================================================================
Attachment data| |Created an attachment (id=
| |932)
Reproduction recipe b
| |y Norbert Buchmuller

--------------------------------------------------------------------------------

------- Additional comments from stsp@... Fri Sep 5 17:15:39 -0700 2008 -------
Created an attachment (id=932)
Reproduction recipe by Norbert Buchmuller

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@...
For additional commands, e-mail: issues-help@...

From forum: subversion - issues

[Issue 3282] replacing symlink with other symlink results in plain file on merge

2008-09-05T17:15:39Z

From forum: Subversion Dev

Re: bug candidate: replacing symlink with other symlink turns to plain file on merge

2008-09-05T17:14:13Z

On Fri, Sep 05, 2008 at 06:50:55PM -0400, Karl Fogel wrote:

> [originally misposted in the wrong thread]
>
> Wait, I think I've got it!
>
> The problem is that the "svn:special" property is set to "link" on both
> the old and new file, so it never appears as a prop diff -- nor should
> it, since there's no difference.
>
> But (I think) the code that handles the "svn:special" property only gets
> activated when the property is added or removed. (I guess it would also
> get activated if the property value changed, but in practice, it's
> always "link" right now, since the details appear in the file text.
> Thus our concern here is with the property being added or removed.)
>
> I haven't investigated this line of reasoning yet, but will later
> tonight if no one beats me to it.
>
> -Karl
>

I've filed this so we don't forget about it:
http://subversion.tigris.org/issues/show_bug.cgi?id=3282

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

From forum: Subversion Dev

[Issue 3282] New - replacing symlink with other symlink results in plain file on merge

2008-09-05T17:11:03Z

http://subversion.tigris.org/issues/show_bug.cgi?id=3282
Issue #|3282
Summary| replacing symlink with other symlink results in plain
| file on merge
Component|subversion
Version|trunk
Platform|PC
URL|
OS/Version|All
Status|NEW
Status whiteboard|
Keywords|
Resolution|
Issue type|DEFECT
Priority|P3
Subcomponent|libsvn_client
Assigned to|issues@subversion
Reported by|stsp

------- Additional comments from stsp@... Fri Sep 5 17:11:03 -0700 2008 -------
Quoting from the thread starting here:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=142620

"If a symlink is replaced by a different symlink (svn rm link; ln -s foo
link; svn add link; svn ci), everything goes fine, up to the point when
you try to merge this change to a branch, as on the merge the element
becomes a plain file (instead of a symlink)."

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@...
For additional commands, e-mail: issues-help@...

From forum: subversion - issues

[Issue 3282] New - replacing symlink with other symlink results in plain file on merge

2008-09-05T17:11:03Z

From forum: Subversion Dev

Re: Error when installing new SmartSVN 4 version

2008-09-05T17:02:30Z

syntevo Support-3 wrote:

Dropping a new version on top of an old one is what I meant and that is IMHO
not the designed way of upgrading, even on the Mac, because then orphan files
may remain.

This may a behaviour on Windows but not on the Mac, usually: if you replace a Mac app, which is a folder that appears as one file to the user (a so-called bundle), the entire folder with all its contents gets replaced. That means that nothing of the old app (or folder) remains there. If the app did install other items in other places, those will remains, though - but since the app installed them, it can also control their versions and do necessary replacements and updates there.

From forum: SmartSVN

Re: On commit, svn server to change line ending to unix style for .sh files.

2008-09-05T16:57:34Z

Hi Larry,

Thanks again for the reply and links.

The information appears somewhat contradictory though. The first link implies that I can set enable-auto-props and that I can choose to have it set the eol-style to LF for .sh files. The second link says there is no server mechanism. Did I mis-interpret something?

Fu-Tung

--- On Fri, 9/5/08, Larry Shatzer, Jr. <larrys@...> wrote:

> From: Larry Shatzer, Jr. <larrys@...>
> Subject: Re: On commit, svn server to change line ending to unix style for .sh files.
> To: futung.cheng@...
> Cc: "Ryan Schmidt" <subversion-2008c@...>, users@...
> Date: Friday, September 5, 2008, 6:57 PM
> Now please read
> http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.auto
>
> And you should read
> http://subversion.tigris.org/faq.html#auto-props
>
> -- Larry
>
> On Fri, Sep 5, 2008 at 11:54 AM, Fu-Tung Cheng
> <futung.cheng@...>wrote:
>
> > Thanks for the reply.
> >
> > I read that portion of the book but it just tells me
> what Ryan mentioned
> > before although it isn't very clear that the
> setting is client side only.
> >
> > The scenario I have is that I always want .sh files -
> any other files - to
> > have the unix eol style but I never want to have to
> set them. svn should be
> > smart enough or configurable enough to set this
> without any interaction from
> > my or any other clients behalf.
> >
> > So the question remains, is this feature on the
> roadmap? Why should
> > everytime I want to add a new .sh file to the
> repository I need to manually
> > set the eol:style to CR when the server could say
> "hey that's a .sh file I
> > know what style he wants and just set it".
> >
> > I realize that adding files doesn't occur all the
> time and that some client
> > allow you to select a bunch of files and set all their
> eol:style at once but
> > this is still error prone and much less nice than an
> automated server side
> > setting.
> >
> > Thanks,
> >
> > Fu-Tung
> >
> >
> >

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

From forum: Subversion Users

Re: Error when installing new SmartSVN 4 version

2008-09-05T16:57:23Z

fermion90 wrote:

2) You could move the old application to the trash and restart the Finder (see
the help or just log out and in again). After that you can install the new
version and empty the trash if you like.

Restarting Finder doesn't solve the problem for me, I had already tried that before sending the original message :-)

Yes. Restarting the Finder would only force the Finder to load the new version of the plugin inside SmartSVN, but not release the old plugin if other apps are still running that may be used with the plugin.

The best working solution next to restarting is to log out, as this quits all apps that might possibly use the plugin.

The basic problem is that OS X does not provide a way to unload contextual menu ("CM") plugins on demand. Only the apps that may use those plugins can do that, by quitting.

SmartSVN has to deal with two problems around that:

1. If a new version of SmartSVN gets installed, with an updated version of the plugin, that new plugin has to be loaded by the participating apps, i.e. the Finder. This can only be achieved by restarting the Finder. Then the Finder keeps that plugin open as long as the Finder runs. Meaning that the plugin can't be deleted (e.g. moving it to the Trash and emptying the Trash) as long as the Finder keeps running. This is a general problem with CM plugins.

Note that the CM plugin gets installed in a special folder that's not part of the SmartSVN app. And this CM folder is usually not seen by the user.

2. Now, what if SmartSVN gets de-installed? As much as the Mac user expects to be able to drag-install, he also expects to be able to uninstall by trashing an app. The expection is that SmartSVN's CM plugin would then be uninstalled as well, wouldn't you agree? We do not want to keep a zombie plugin around for the rest of the life of the computer, using up resources and - in the worst case - cause problems with updated OS versions just because the user did not use an Uninstaller to remove the plugin.

Instead of providing a uninstaller or putting a note into a "read me" file that most users are sure to lose or forget, we decided to leave the CM plugin only in the SmartSVN bundle and then place a symlink to the plugin into the special CM folder. That way, once SmartSVN gets deleted, the symlink in the CM folder is not valid any more, and thus doesn't get loaded, hence no resources are wasted.

The problem with this solution is that now the CM plugin which resides in the SmartSVN bundle remains in use as long as the Finder and other apps using it are running. And that leads to the effects you ran into.

Now, do you have a suggestion how to handle this better?

From forum: SmartSVN

Re: svn very slow (was Re: svn log -v very slow)

2008-09-05T16:55:19Z

> So I started to use strace to figure out what was happening. It turned
> out it is blocking on
> /dev/random
>
> So because we don't have enough entropy on our server Subversion is
> slow!
>
> What should I change in my config solve this?
>

If you compiled Subversion from source, you may be experiencing this
problem:
http://subversion.tigris.org/faq.html#slow-private-svnserve

Marshall

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

From forum: Subversion Users

Re: Proposed feature: safer alternative to svnput

2008-09-05T15:59:50Z

David Glasser wrote:
>>> Can it read SRC-FILE from stdin?
>> No, I don't think it can.
>
> Passing /dev/fd/0 doesn't work?

I ... I dunno. Never occured to me to try.

--
C. Michael Pilato <cmpilato@...>
CollabNet <> www.collab.net <> Distributed Development On Demand

signature.asc (196 bytes) Download Attachment

From forum: Subversion Dev

log -g fails on revision 31828

2008-09-05T15:57:26Z

Doing an "svn log -g -r31828 http://svn.collab.net/repos/svn/" fails
for me in the middle of the response with:

svn: REPORT of '/repos/svn/!svn/bc/31828': 200 OK (http://svn.collab.net)

Is this a bug in Subversion or could it be related to the "Historical
surgery" as mentioned on http://svn.collab.net/ ?

I'm using svn version 1.5.2 (r32768)

Without -g, it works fine:

r31828 | cacknin | 2008-06-21 03:16:24 +0200 (Sat, 21 Jun 2008) | 7 lines

On the svnpatch-diff branch, bring up to sync with trunk(...)

Eirik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

From forum: Subversion Dev

Re: svn list no working for some working directories

2008-09-05T15:53:04Z

Sorry, the below was meant to be in response to another thread, please
ignore it. I've reposted in the correct thread now.

Karl Fogel <kfogel@...> writes:

> Wait, I think I've got it!
>
> The problem is that the "svn:special" property is set to "link" on both
> the old and new file, so it never appears as a prop diff -- nor should
> it, since there's no difference.
>
> But (I think) the code that handles the "svn:special" property only gets
> activated when the property is added or removed. (I guess it would also
> get activated if the property value changed, but in practice, it's
> always "link" right now, since the details appear in the file text.
> Thus our concern here is with the property being added or removed.)
>
> I haven't investigated this line of reasoning yet, but will later
> tonight if no one beats me to it.
>
> -Karl
>
> Karl Fogel <kfogel@...> writes:
>> John McGrath <john.mcgrath@...> writes:
>>> My understanding is that 'svn list' will show the contents of the
>>> repository for the same path as the current directory in the
>>> workspace.
>>>
>>> For example, if my workspace has
>>> dir1/
>>> dir2/
>>> file1
>>>
>>> but the repository has a new directory recently added, called dir3,
>>> svn ls would report
>>> dir1/
>>> dir2/
>>> dir3/
>>> file1
>>>
>>> i.e. it shows me the contents of the repository.
>>>
>>> However, if the local workspace was originally checked out with the -N
>>> (non-recursive) command,
>>> running svn ls would only show me the directories I have, it would not
>>> show me dir3!
>>
>> I cannot reproduce this. Could you give a complete reproduction recipe
>> please (that is, a script)? My transcript is below.
>>
>>> This appears to be a bug - becuase if not, what advantage is svn ls
>>> over plain ls, in this case?
>>> I have tested this will the latest svn 1.5.2, and it still operates in
>>> this way.
>>>
>>> The same thing goes for svn update, if the local working direcotory
>>> was originally checked out with -N, running svn update will only get
>>> the contents of directories that are in the workspace.
>>> It would be great if there was a switch to force recursion, like -R or
>>> something, or even -R n, where n would be a number of levels.
>>
>> -N is deprecated; we use --depth=foo now. And the --set-depth option
>> does what you want.
>>
>>> At the very least, I think this is a bug in the terms of svn ls,
>>> changing svn update to work as described is a bonus!
>>
>> The reported 'svn ls' behavior would be a bug, I think; but I cannot
>> reproduce it with latest trunk Subversion (which is similar to 1.5.2,
>> though not exactly the same).
>>
>> The 'update' behavior is as-designed, and you should use --set-depth to
>> expand ("unfold") the directories.
>>
>> Here's my repro script:
>>
>> ---------------------------------------------------------------------------
>> #!/bin/sh
>>
>> # The next line is the only line you should need to adjust.
>> SVNDIR=/home/kfogel/src/subversion
>>
>> SVN=${SVNDIR}/subversion/svn/svn
>> SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
>> SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
>>
>> URL=file:///`pwd`/repos
>>
>> rm -rf repos wc import-me
>>
>> ${SVNADMIN} create repos
>>
>> echo "### Making a Greek Tree for import..."
>> mkdir import-me
>> mkdir import-me/trunk
>> mkdir import-me/tags
>> mkdir import-me/branches
>> mkdir import-me/trunk/A
>> mkdir import-me/trunk/A/B/
>> mkdir import-me/trunk/A/C/
>> mkdir import-me/trunk/A/D/
>> mkdir import-me/trunk/A/B/E/
>> mkdir import-me/trunk/A/B/F/
>> mkdir import-me/trunk/A/D/G/
>> mkdir import-me/trunk/A/D/H/
>> echo "This is the file 'iota'." > import-me/trunk/iota
>> echo "This is the file 'A/mu'." > import-me/trunk/A/mu
>> echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
>> echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
>> echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
>> echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
>> echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
>> echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
>> echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
>> echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
>> echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
>> echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
>> echo "### Done."
>> echo ""
>> echo "### Importing it..."
>> (cd import-me; ${SVN} import -q -m "Initial import." ${URL})
>> echo "### Done."
>> echo ""
>>
>> ${SVN} co -q -N ${URL}/trunk wc
>>
>> cd wc
>> ${SVN} ls
>> cd ..
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

From forum: Subversion Dev

Re: bug candidate: replacing symlink with other symlink turns to plain file on merge

2008-09-05T15:50:55Z

[originally misposted in the wrong thread]

Wait, I think I've got it!

The problem is that the "svn:special" property is set to "link" on both
the old and new file, so it never appears as a prop diff -- nor should
it, since there's no difference.

But (I think) the code that handles the "svn:special" property only gets
activated when the property is added or removed. (I guess it would also
get activated if the property value changed, but in practice, it's
always "link" right now, since the details appear in the file text.
Thus our concern here is with the property being added or removed.)

I haven't investigated this line of reasoning yet, but will later
tonight if no one beats me to it.

-Karl

Karl Fogel <kfogel@...> writes:

> BUCHMULLER Norbert <norbi@...> writes:
>> I found a bug in Subversion. Can someone pls test it on the latest
>> version? (Or tell me if it's a known bug that I overlooked.)
>>
>> If a symlink is replaced by a different symlink (svn rm link; ln -s foo
>> link; svn add link; svn ci), everything goes fine, up to the point when
>> you try to merge this change to a branch, as on the merge the element
>> becomes a plain file (instead of a symlink).
>>
>> Note that this bug is similar to issue 2064, but is not the same. (Issue
>> 2064 is about the merge of a change creating a new symlink, this one is
>> about the merge of a change that replaces a symlink with a different one.
>> Just to be sure, I tested that it is not a regression of 2064.)
>>
>> Note2: I understand that replacing an element this way is silly (it
>> creates a new element with the same name but separate version history).
>>
>> See the attachment (rm_symlink+add_symlink+merge.sh) for a recipe how to
>> reproduce the bug.
>
> Thank you for the excellent reproduction script. I can also reproduce
> the bug, using your script.
>
> When I traced in with GDB, I set breakpoints on svn_client_merge_peg3(),
> and on each of the merge_callbacks in libsvn_client/merge.c:
>
> /* The main callback table for 'svn merge'. */
> static const svn_wc_diff_callbacks3_t
> merge_callbacks =
> {
> merge_file_changed,
> merge_file_added,
> merge_file_deleted,
> merge_dir_added,
> merge_dir_deleted,
> merge_props_changed,
> merge_dir_opened,
> merge_dir_closed
> };
>
> Here's what I found:
>
> Breakpoint 11, svn_client_merge_peg3
> (source=0x9b0f5e0 "", ranges_to_merge=0x9b0db18,
> peg_revision=0xbfa635d8, target_wcpath=0x806fff8 "",
> depth=svn_depth_unknown, ignore_ancestry=0, force=0, record_only=0,
> dry_run=0, merge_options=0x0, ctx=0x9b0e338, pool=0x9b0d990) at
> subversion/libsvn_client/merge.c:6569
> (gdb) c
> Continuing.
>
> Breakpoint 5, merge_file_deleted
> (adm_access=0x9b0f710, state=0xbfa62d4c, mine=0x9bb2710 "link",
> older=0x9bb2810 "/tmp/tmp", yours=0x9b75f68
> ".svn/tmp/tempfile.tmp", mimetype1=0x0, mimetype2=0x0,
> original_props=0x9bc1348, baton=0xbfa63428) at
> subversion/libsvn_client/merge.c:1062
> (gdb) c
> Continuing.
>
> Breakpoint 4, merge_file_added
> (adm_access=0x9b0f710, content_state=0xbfa62d5c,
> prop_state=0xbfa62d58, mine=0x9bc20e8 "link", older=0x9b75f68
> ".svn/tmp/tempfile.tmp", yours=0x9bc2380 ".svn/tmp/tempfile.2.tmp",
> rev1=0, rev2=3, mimetype1=0x0, mimetype2=0x0,
> prop_changes=0x9bc20f0, original_props=0x9b75e18, baton=0xbfa63428)
> at subversion/libsvn_client/merge.c:821
> (gdb) c
> Continuing.
> --- Merging r3 into '.':
> R link
>
> Hmmm, at this point, 'link' on disk is not a symlink. The "svn:special"
> prop (needed to turn it into a symlink) was not delivered via
> prop_changes and original_props (I stepped through earlier to make
> sure). Then later we hit this:
>
> Breakpoint 10, merge_props_changed
> (adm_access=0x9b0f710, state=0xbfa62ef4, path=0x9b8c6c8 "",
> propchanges=0x9b8c6a8, original_props=0x9b927d0, baton=0xbfa63428)
> at subversion/libsvn_client/merge.c:536
>
> ...However, when I step through, it just sets some svn:entry props. It
> still didn't supply svn:special. After that, we don't hit any merge
> callbacks (except for merge_dir_closed(), I think).
>
> I haven't traced the problem to its source yet, but I'm posting this in
> hopes of saving you or someone else some time, if you decide to try
> debugging it.
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

From forum: Subversion Dev

Re: svn list no working for some working directories

2008-09-05T15:50:16Z

Wait, I think I've got it!

The problem is that the "svn:special" property is set to "link" on both
the old and new file, so it never appears as a prop diff -- nor should
it, since there's no difference.

But (I think) the code that handles the "svn:special" property only gets
activated when the property is added or removed. (I guess it would also
get activated if the property value changed, but in practice, it's
always "link" right now, since the details appear in the file text.
Thus our concern here is with the property being added or removed.)

I haven't investigated this line of reasoning yet, but will later
tonight if no one beats me to it.

-Karl

Karl Fogel <kfogel@...> writes:

> John McGrath <john.mcgrath@...> writes:
>> My understanding is that 'svn list' will show the contents of the
>> repository for the same path as the current directory in the
>> workspace.
>>
>> For example, if my workspace has
>> dir1/
>> dir2/
>> file1
>>
>> but the repository has a new directory recently added, called dir3,
>> svn ls would report
>> dir1/
>> dir2/
>> dir3/
>> file1
>>
>> i.e. it shows me the contents of the repository.
>>
>> However, if the local workspace was originally checked out with the -N
>> (non-recursive) command,
>> running svn ls would only show me the directories I have, it would not
>> show me dir3!
>
> I cannot reproduce this. Could you give a complete reproduction recipe
> please (that is, a script)? My transcript is below.
>
>> This appears to be a bug - becuase if not, what advantage is svn ls
>> over plain ls, in this case?
>> I have tested this will the latest svn 1.5.2, and it still operates in
>> this way.
>>
>> The same thing goes for svn update, if the local working direcotory
>> was originally checked out with -N, running svn update will only get
>> the contents of directories that are in the workspace.
>> It would be great if there was a switch to force recursion, like -R or
>> something, or even -R n, where n would be a number of levels.
>
> -N is deprecated; we use --depth=foo now. And the --set-depth option
> does what you want.
>
>> At the very least, I think this is a bug in the terms of svn ls,
>> changing svn update to work as described is a bonus!
>
> The reported 'svn ls' behavior would be a bug, I think; but I cannot
> reproduce it with latest trunk Subversion (which is similar to 1.5.2,
> though not exactly the same).
>
> The 'update' behavior is as-designed, and you should use --set-depth to
> expand ("unfold") the directories.
>
> Here's my repro script:
>
> ---------------------------------------------------------------------------
> #!/bin/sh
>
> # The next line is the only line you should need to adjust.
> SVNDIR=/home/kfogel/src/subversion
>
> SVN=${SVNDIR}/subversion/svn/svn
> SVNSERVE=${SVNDIR}/subversion/svnserve/svnserve
> SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
>
> URL=file:///`pwd`/repos
>
> rm -rf repos wc import-me
>
> ${SVNADMIN} create repos
>
> echo "### Making a Greek Tree for import..."
> mkdir import-me
> mkdir import-me/trunk
> mkdir import-me/tags
> mkdir import-me/branches
> mkdir import-me/trunk/A
> mkdir import-me/trunk/A/B/
> mkdir import-me/trunk/A/C/
> mkdir import-me/trunk/A/D/
> mkdir import-me/trunk/A/B/E/
> mkdir import-me/trunk/A/B/F/
> mkdir import-me/trunk/A/D/G/
> mkdir import-me/trunk/A/D/H/
> echo "This is the file 'iota'." > import-me/trunk/iota
> echo "This is the file 'A/mu'." > import-me/trunk/A/mu
> echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
> echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
> echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
> echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
> echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
> echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
> echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
> echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
> echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
> echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
> echo "### Done."
> echo ""
> echo "### Importing it..."
> (cd import-me; ${SVN} import -q -m "Initial import." ${URL})
> echo "### Done."
> echo ""
>
> ${SVN} co -q -N ${URL}/trunk wc
>
> cd wc
> ${SVN} ls
> cd ..
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

From forum: Subversion Dev