It is really a big problem.

This could be related to T6608. We are having the same issue when someone issues a commit with a long summary.

You mean something like "Create Similar Repository To..."?

We're more likely to implement this by letting you clone an existing repository than by setting global defaults. Would that cover your use case?

T5722 mentions a use case for this related to regulatory compliance (roughly, period audit if segments of a codebase). This is similar to the Mochi/i18n use cases.

Support Impact I haven't triaged, but this looks like a bug with no recourse.

I don't believe we plan to pursue this. T4411 explains a bit how we're approaching this in Maniphest.

Well actually it's the same exception, the message was slightly changed ~26 days ago, see rPHU0135e57181a91e1f342338d62782754e0bd31e59
Ok so let's sum this up:

Looks similar to T6433, which is fixed by T6350.
Tried to upgrade, but nope still the same issue.

Got the very same issue over here.

Alright, we seem to agree on the idea of merging Audit under Diffusion, yet leaving a configuration option to enable/disable the post-commit review workflow.

• This actual change is straightforward (update getTitle() and getTitleForFeed() in DifferentialTransaction), but testing it isn't.
• When you get here, let me know and I'll help you set up a repository you can push test commits to.

I'm still getting this problem with the latest pull :(
A few hundred thousand copies of my key every week :(

Another case, when this can be happening is during file/folder coping. Even through I can copy within the repository svn-subpath the revision reported by svn log as copyfrom-rev is last at the moment of copy per whole SVN repository and not just sub-path: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/repository/worker/commitchangeparser/PhabricatorRepositorySvnCommitChangeParserWorker.php;fa77fdd168d4f4f0a306e3b9867b5f09481fb6d1$50

I don't really care whether the application is separate or inside some super-Diffusion; I guess I have a modest preference for super diffusion because it feels like organic audits happen while browsing the code and otherwise you'd just go to audit when you knew there was a problem or something?

It seems reasonable for them to be separate.

@chad / @btrahan, do you think this is worth separating? Offhand, the integration points I can think of are:

@epriestley, could you please confirm that a described behavior is a bug?

@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.

It appears that during commit discovery on a repository (when daemon is looking for new commits) each commit wants to set it's own parent commit. And that parent commit is calculated as commitIdentifier -1 for SVN repositories. This is incorrect when we're dealing with SVN repositories, where only sub-path is imported.

I've added whitespace control for audits. It looks like this.

Closed by commit rPa414fc497f3b.

Some more info I was able to find out. The commits:

• have importStatus 15 (in contrast to 1039 for all other commits)
• have "foreign-svn-stub":true in repository_commitdata table in the commitDetails field

@taoqiping if you can reproduce the issue on this install, we can take a look, otherwise I'll close this out.

Closed by commit rPd2ea0bc5f0df.

Check out https://secure.phabricator.com/book/phabcontrib/article/bug_reports/ on what we look for in bug reports. Specifically, we need to be able to build a repro case. Feel free to repro by uploading a diff to this server if you need.

Op woensdag 12 november 2014 heeft joshuaspence (Joshua Spence) <
noreply@phabricator.com> het volgende geschreven:

Closed by commit rP22551d106d35.

I've submitted a Differential Revision with a fix to described issue.

Solution:

1. if we're importing full SVN repository, then current implementation is correct
2. if we're importing sub-path only then we should do svn log svn://repo.url/sub/path --revision current_revision:1 --limit 1 command and get returned revision back

Closed by commit rP786232c4bc29.

Digging even deeper I've found out that diffusion.commitparentsquery API call is used to determine commit parent. However it seems to work like this for SVN repositories: parent of this commit is this commit minus one: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/diffusion/query/lowlevel/DiffusionLowLevelParentsQuery.php;120a7d91644753734bbdcdc7f8b50385829a0a5d$73

While debugging the issue I've figured out possible cause: in SVN the code, that detects previous commit on that file line somehow goes past sub-path of current repository (I wonder how this even possible) and commitIdentifier from another repository is found. When that commitIdentifier is combined with current repository callsign this results in bad commit.

I think it's:

In T3189#32698, @epriestley wrote:

Specifically, the implementation will probably look like:

• [project] in titles implies project;
• #project in body fields implies project;
• Project: project, Projects: project, Tag: project or Tags: project imply project.

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

T4245#53345 has some guidance here. This task as a whole likely involves both easy and not-so-easy pieces, but the first two bullet points there should be relatively approachable:

In T4151#53936, @epriestley wrote:

The only thing remaining here is:

• When creating a hosted repository, it defaults to having all its hosting options off.

Instead, these should probably be something like:

• SSH: Read/Write if diffusion.ssh-user is set?
• HTTP: Read/Write if diffusion.allow-http-auth is set?

I don't think we have a totally unambiguous way to pick defaults, but those are probably better than the status quo.

I can't reproduce this fully and then have questions....

ooh, I was thinking "high availability" clone....

Each copy of a commit in a tracked repository has a unique PHID, yes. This is intentional -- it would be weird/confusing if commenting on rXabcdef1234 mirrored to rYabcdef1234 just because the "X" and "Y" repositories were copied from one another at some point in history. The two commits might also have totally different view/edit policies, etc.

I've got desired effect by adding my code into custom Harbormaster step, that I've attached through Herald to be executed on new commits, see T6518.

Does it also mean that each clone allocates a new PHID for each commit (Because "edges")?

Fix for this is probably some kind of "ignore references in this repository" flag. Prior to adding object mentions you could effectively do this by disabling autoclose, I think, but I believe mentions now punch through autoclose.

@aklapper, T6367 discusses the email thing in more detail.

In T6516#83228, @aklapper wrote:

This triggered a comment in https://phabricator.wikimedia.org/T1191 which displays for me (being an admin in that instance):

Restricted Application added a commit: Restricted Commit.

...or what I had just written up, with an added aspect of different levels of information being revealed between web vs mail:

Hi Chad,

Closing for due to lack of feedback, but hopefully you sorted stuff out. Feel free to let us know if not.

Thanks, that works. Our project also need a conduit call for creating a new credentialPHID. I looked through the conduit calls and don't see it. Am I missing the option? Or can it be added?

Before you've replied I've tried to implement this locally and I was very surprised when all demons at once picked up the work and PhabricatorRepositoryCommitParserWorker::doWork method was executed 5 times. Is this normal?

1. Before you've replied I've tried to implement this locally and I was very surprised when all demons at once picked up the work and PhabricatorRepositoryCommitParserWorker::doWork method was executed 5 times. Is this normal?
2. There are no protection inside to prevent such things from happening, like daemon who wants to parse the commit locks that commit, which should prevent others from doing the same in parallel.
3. Is there other (non-event based) way to do custom code after commit is parsed? If so, then where this code should be placed?

We don't plan to implement this. We generally intend to move away from events: they're too complex for most users and we've found better approaches in most cases for most reasonable use cases.

Great, thanks. Checking it out.