I would personally pony up a couple of hundred at least, just for all the times that @epriestley has helped me out with responses that were detailed and incredibly helpful, without any visible signs of annoyance. :)

Our projects make use of mercurial tags, specifically for marking versions and for managing some repository dependencies (preventing commits being pushed upstream to repo A unless they already exist upstream in repo B).

At least Python and Mercurial itself use tags extensively, and there are many more projects that do.

They're a function of an individual commit instead of being a function of the repository as a whole, so we'd have to do a lot more work to support them (it's not meaningful to, say, "list all tags in the repository", as it is with Git), and I suspect they're not used much in the wild because of how they work. I'm not sure if this is true or not.

Login as webuser , run svn checkout command and accept the certificate permanently .

In T1130#47372, @epriestley wrote:

Repri to "basically never" now that I have learned more about Mercurial tags.

The newly added method removeMissingCommits was causing a lot of unneeded thrash on our mercurial repository. We have 140 branches, and phabricator was launching a process to check each revision every 15 seconds, and rather severely thrashing our disk. It seems to me that there's no need to call this method for mercurial branches, since the information contained in $branches was already obtained by running 'hg log' and should be up to date.

I ran into a 404 repository not found after changing Diffusion from public to All users. The repository in question is set to read and editable by users of a specific project. I was able to re-access the repository by setting Diffusion back to public (the repository still has restricted access).

Tracking moves and fixes of these things seems like the hard part: it would maybe be nicer to see "all places in the codebase a task is currently mentioned", not necessarily "all places a task has ever been mentioned". But maybe this isn't actually that important.

Another (not necessarily good) attack on this would be to extract these with a linter (similar to the TODO linter), and then maybe, uh, let lint messages have an object PHID on them? I guess? This feels real sketchy but maybe there are some other reasonable things we could do which could justify it.

I installed phabricator using the shell script ( http://www.phabricator.com/rsrc/install/install_rhel-derivs.sh ) and meet the same error. When I run the svn command like

Yes. I have assigned the credential into repo link. Please check the image.

And the credential was assigned to the repo?

Hi Mnkras,

Hi mnkras,

When you setup the import there is a screen that has you add credentials. That would be the ssh key or the password, if you go to the repo in Diffusion you can add the credentials there as well.

Yes. That repository server having authentication like as password and ssh public key, How to add this key or password into the Phabricator. Can you explain the procedure.

Is the repo you are cloning public? or does it require authentication, if it requires authentication, you need to make sure that you have uploaded/generated/added the credentials to phabricator so that it can connect.

Hi epriestley,

@hach-que, this is what you were asking about in IRC.

Yes, that solves it. Thanks!

Restart Apache (if you use Apache) or php-fpm (if you use nginx + php-fpm), and let me know if you still see the issue?

This happened again today (for my own future reference, see D20770 on our install).

Going with the T8202 resolution plan.

I turned off auto-close on the main repository, and revisions pushed to 'A' no longer associate with the main repository. However none of the revisions for the main repository auto-close.

"You need to cron some stuff syncing master or it will sometimes be kind of slow" is acceptable from my point of view. Things I can solve with code is preferable to 'please debug my snowflake workstation where I did strange where I did strange things with arc and git'.

(Not sure if my comment in T8090 should actually be here).

We could really push two refs: phabricator/diff/12345 and phabricator/base/12345. To phabricator/base/12345, we push the first parent of the last thing that pops out of git log HEAD --not --remotes -- (that is, the first ancestor of the diff which is also present in any remote)?

From D13041, it looks like the first time git does a push to a totally separate staging area it pushes a lot of extra data, probably because none of the heads in the remote are ancestors of the head being pushed, so it can't detect that their ancestries are 99.9% identical.

As a note, the title tagging you did in {D13040}, is basically how I've been having users do this in my install. We've been putting the logical project/branch like [branch_name] in a lot of titles to get that info into the major panels so that diffs don't require a clickthrough for context.

I configured this for our repos; only hiccup so far is that there's no way to disable "Commit Hook" Herald rules right now so the first pushes (which pushed the entire repo history) took a little while. Normal "arc diff" staging pushes only take about a second.

We were discussing GH magic branches lately, and it turns out you can do this:

git fetch origin refs/pull/33/head:pr33

@epriestley: Ok, thanks for clarification. I will refer people here if it comes up again :)

Yep, that's right. My plan for the upstream to move forward in the short term (until we build virtual refs) is:

If I'm reading this right, with the tag approach & staging != main-repo, unless someone has specified things manually in .git/config they (well arc) can do git push to arbitrary places but since the staging repo isn't a configured remote none of {fetch,pull,clone} will know anything about it. I think that is a satisfactory level of cleanliness for both the main & local repos.

In the general case, this is working as intended. Specifically, it's intentional that we accept linebreaks in the middle of a "Fixes X, Y" statement, because linebreaks aren't always added explicitly by users.

It looks like we can push to some secret place:

I have this working, but pushing to tags in the same repo is pretty leaky. The docs say this of git fetch:

Yes that is a more succinct description. Using that same description, repository 'B' would be where primary development happens, and hence more Differential revisions are created. Ideally revisions on repository 'B' would still auto-close. I was hoping for an option that had similar behavior but was a little inverse -> instead of configuring auto-close for repositories 'B', 'C', etc. there would be some option on 'A' to ignore commits on 'B', 'C', etc.

Wow, thanks a lot for that insightful feedback.
I understand that some of these actions we are taking are definitely not conventional and should not be integrated as is.

Presuming this is a Bitnami issue.

From my side, I'm playing around with Phabricator for my personal/private repo hosting (not even having settled on it). As with most FOSS projects, this means I'd be contributing fixes or enhancements I encounter (and am able to work on in terms of complexity), but don't have monetary budget to spend. However, @techdragon's suggestion sounds fair for everyone using this in a professional/work environment.

If the estimate is 20 hours, then perhaps those of us still looking for this more earnestly can pass around the collection plate and collectively pay for it. 18 people are subscribed to this issue, if even 3 of us are willing to pony up the dough, then this goes from ~$3000 to ~$1000, and suddenly I can say "look finance guy, we spend $100 a month on private github repos, this $1000 eliminates that year over year cost".

Ah, thanks! That's helpful.

Most of the rules we are implementing are directly related to Differential.
We are for example, reporting or blocking pushes to the repositories based on:

• the number of open revisions (blocking others or action required) the author has.
• the last update and/or creation dates of any open item for that author.
• the existence of a revision for all the commits being pushed (which I believe Herald already supports).
• the status of the revisions associated to the commits.

Any of these items can be activated of de-activated based on the author.

You can pay us to prioritize this; see Paid Prioritization for details. I've previously quoted this as about 20 hours of work, and I think that's still accurate.

Can you provide some examples of what you want the rules to do? There are probably three general ways forward here:

You shouldn't, no. arc uses other information (mostly working copy path on disk, IIRC) in that case.

For SVN, how will this differ from current workflow when we have two working diffs from same repo but different "projects"? Will we now need to specify --update and --revision for arc diff and arc commit where we wouldn't need to previously? That would be sad.

Is there anything I can do to help you on this or is it already taking its course?

I may be misunderstanding, but here's what I think is happening from your description:

I can try this, but wouldn't I want to disable auto-close on the current-version branch? The majority of work is being done on the current-version, but a significant amount of work is being done on prior-version in-tandem. Or are you referring to the prior-version having it's Auto-close turned off, or both? Unfortunately I won't be able test any of this till next week.

Right -- can you disable Autoclose on the version-branch repository to work around this? Disabling it should stop commits to it that repository from associating with revisions, so the repository will never "steal" the revision (basically, Differential will just ignore the commit, even though it will still show up in Diffusion).

Commits from all version repositories appear to associate correctly. When the change is first developed it is on the prior version repository and creation of the revision properly associates it (through arc diff). But when doing our land process, it looks like since the repository which receives the commit first is the current version branch instead of the prior version branch, the revision's repository field is automatically changed to the current version's repository and closed before the commit makes it up to the prior version branch.

The MIME type of these files is detected differently (text/plain vs text/x-php). We can probably force these to text/plain safely in all cases, but this has some security implications.