Its suggested to use Arcanist. e.g.

Hi chad,

Looks like it was added in 1.5:

That's possible. The pertinent code has been in the codebase since the "initial commit" and hasn't really seen any changes other than this - rARC0788220af41668e447c277ae4472dde73cf85a26 - way back in December of 2011.

Maybe this used to be a problem with older versions of svn?

...at least to me then.

Also, looking at the code, I think D 3111 on your system is possibly including test/prof_burn.py

Can you verify that the corresponding svn commit command would work in this case?

Also, note that arc commit is perfectly fine with the untracked files when there are no changes on the directory itself (i.e. if I hadn't edited the svn props on .)

I am not familiar with any such restriction being imposed by subversion.

I thought to svn commit you couldn't have untracked files? i.e. if you ran svn commit you'd also get an error about the untracked file? Or said differently, isn't this working exactly as its supposed to, telling you about the untracked file that is not in the commit, etc?

You are certainly welcome to update your Subversion to something more modern, though I have no idea if that's an issue.

T4778

Hello, any update?

In T7068#93405, @chad wrote:

What version of Subversion are you using?

What version of Subversion are you using?

Yeah, understood, certainly wasn't suggesting that this be a priority.

In the screenshot provided, all the commits I see have all the context I need to make sense of them. I can further click on them for additional context. There is the callsign, the message, and if a project is tagged, it should show up as well. That is currently all the information we intend to provide against all three VCS we provide support for.

Problem: items don't always show enough context to make sense of them from feeds. Example in screenshot.

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#describe-problems

The issue I'm having is exemplified in the attached screenshot.

Please see https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ regarding requesting features here. Mostly, we just need to know the problem you are having, ie, 'when I read my feed, the message isn't helpful since I don't know X, Y, or Z'. Based on you wanting additional context for a commit, T6973 seemed correct.

Hmmm, based on what you merged this with, I don't think you quite understood what I was saying.

@epriestley does this mean you'll merge your fix?

There's no server detection. (Just to clarify as I get confused here -- the Phabricator server uses the SVN client to get information from some other SVN server.) Theoretically, we can get away without server detection persay since the SVN clients are supposed to clearly indicate that problem and Phabricator doesn't offer SVN-based hosting, so the admin must be doing that too...? (Hand-waving... hi!)

@btrahan, I think you added client detection of 'bad vcs clients', does that include server versions as well?

Hi, This is a svn client problem. Update the svn client to 1.8x and it should work fine.

Unfortunately changing the DiffusionSvnRawDiffQuery::executeQuery as I originally suspected might be wrong because for example the DiffusionCommitController::buildRawDiffResponse specifically passes path parameter that it expects diff to be built against.

In particular, "Changed Files" will include all the content, because all of the files have changed -- they were previously empty, and now they have a lot of content.

Copying a file creates a new file, so this is working as expected. The diff is not empty: it adds all the copied files.

It is really a big problem.

Are you sure?

Are you sure? In the executed svn diff command the final argument would be svn://some.repo.com/sub-path/here if only sub-path/here is imported in a particular repository.

We can't always use paths relative to the subpath because a commit may affect files under the subpath and also files outside of the subpath. In this case, we should faithfully represent the commit (show all files), not discard the changes outside of the subpath.

Yes, it does.

@aik099, can you confirm this fixes it? I don't have a test case readily available:

@altendky , does doing svn up help? I saw this error a few times, when I've commited a sub-folder, but haven't done svn up afterwards to line up revisions of each top level folders in the working copy.

@aponomarenko could you please send a fix via Differential?

@epriestley, could you please confirm that a described behavior is a bug? If that is a bug, then please take a look at the submitted fix.

This is easy if you have an imported SVN repository with an "Import Only" subdirectory, which is really complicated.

Here's the best link I could find...

Thanks holmboe! I think we got exactly the same issue. But is there a chance that the svn hosting used to be correct, and broke by any of the recent versions?

I haven't looked at it. Reviewing code takes time, and this feature isn't a priority.

It's ok if you don't merge it to the upstream (I can merge it my fork regardless of this). But what I'm asking if implementation is correct and code is following Phabricator coding guidelines and such. Maybe this needs to be unit tested somehow?

Pursuing this or reviewing the patch is a very low priority for us because use of changelists appears to be very rare among Phabricator users.

@rudykocur , does the change you've made work as expected and no issues were found so far?

Now has a solution to this problem?

FYI, it also works with svn 1.7.10, but that was tested on a different box, so I can not be 100% sure it is just the svn version. It does seems there have been plenty of bug fixes between 1.7.4 and 1.7.10, so once we update the box where this has been happening I should be able to know for sure.