How to clone codeplex code with current changes in tortoiseSVN or tortoiseHG - asp.net

I want to download the code of nopcommorce with this changes
http://nopcommerce.codeplex.com/SourceControl/changeset/f438f188fa4e
For get this I am going to clone the code and it's not make clone. I got error that
% hg clone --verbose -- https://hg.codeplex.com/nopcommerce .
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: stream ended unexpectedly (got 1718536 bytes, expected 3694604)
[command returned code 255 Sat Oct 27 14:51:03 2012]
% hg clone --verbose -- https://hg.codeplex.com/nopcommerce .
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: stream ended unexpectedly (got 997670 bytes, expected 5238782)
[command returned code 255 Sat Oct 27 14:53:37 2012]
Can someone tell me how I can got it worked. I have both tortoseHG and tortoiseSVN both installed..
how I can got the code on my computer with the recent changes.

It's mercurial repo, you have to use only hg
It's big repo, for such cases clone to some non-tip revision and set of pulls may work better (-r option for clone|pull)
% hg clone --verbose -- https://hg.codeplex.com/nopcommerce .
requesting all changes
adding changesets
adding manifests
adding file changes
added 3021 changesets with 54579 changes to 15033 files (+6 heads)
...
4280 files updated, 0 files merged, 0 files removed, 0 files unresolved
[command completed successfully Sat Oct 27 15:48:37 2012]

Related

Is origin/CONTRIBUTING.adoc updated for 4.x codebase?

I'm trying to follow the CONTRIBUTING.adoc steps to get my dev env set up (for the first time). But this hack/env hack/build-base-images.sh is erroring out on me. If I git checkout release-3.11, the script finishes, and I can make release as well. But with 4.1 or 4.2 codebase, it immediately spits out;
[openshift/origin-source] open /go/src/github.com/openshift/origin/images/source/Dockerfile: no such file or directory
[WARNING] Retrying image build for openshift/origin-source:latest, attempt 1...
[openshift/origin-source] open /go/src/github.com/openshift/origin/images/source/Dockerfile: no such file or directory
[ERROR] hack/build-base-images.sh:56: `return "${result}"` exited with status 1.
I'm on RHEL 7.6 with docker 1.13 and go 1.13. Is the doc updated for 4.x codebase, and thus it should "just work," or something must be wrong with my RHEL server?
https://github.com/openshift/origin/blob/release-4.2/CONTRIBUTING.adoc

Resolving problems in git am

I've got a couple of problems with git am. I had a patch made from git format-patch and it usually worked nicely.
Now I just merged a couple of things and git am failed with:
Applying: Improve speed of computes
error: patch failed: product_cost_incl_bom/models/product_product.py:38
error: product_cost_incl_bom/models/product_product.py: patch does not apply
Then how do I know why the patch doesn't apply...Now the weird thing is this:
I then did this:
$: patch -p1 .git/rebase-apply/patch
patching file product_cost_incl_bom/__openerp__.py
patching file product_cost_incl_bom/models/mrp_bom.py
patching file product_cost_incl_bom/models/product_product.py
Hunk #2 succeeded at 39 with fuzz 1
So why does git am fails but patch doesn't. And what's the fuzz 1?

Grunt - Warning: path must be a string Use --force to continue

I've been using grunt for a long time and working fine. Now, suddenly, it arises a warning and abort the task when running the sftp deploy.
The warning is:
Completed in 1.366s at Tue Aug 02 2016 21:36:06 GMT+0200 (CEST) - Waiting...
File "../build/footer.php" changed. Running "sftp-deploy:build" (sftp-deploy) task Warning: path must be a string Use --force to
continue.
Aborted due to warnings.
What's wrong? I have not changed gruntfile.js.
Based on the OP's comments, here's what may have been happening: The cache option "remembers" paths... so what might have happened is it "remembered" your build path, even though that build path may have been destroyed and recreated. If a directory is cached, then deleted, then another directory with the same name is created, those two directories are not the same, and when your task sftp-deploy task looked for the directory, it was actually looking for the old one. The new one, though it had the same name, was technically a different file entry in the operating system.

making first commit into diffusion git :Phabricator

I am setting up a phabricator server and i am observing the below issue, both from my diffusion repository Status window and the daemons.log file
Error updating working copy: Command failed with error #128!
COMMAND
git log --format='%H%x01%P%x01%ct' --all --
STDOUT
(empty)
STDRR
fatal: bad default revision 'HEAD'
After reading on this issue, i figured out that this is a common issue with bare repositories without first commits. So i tried committing from my local system through repository http URI, but it is returning a 500 exception.
below is the error message i pulled out from phabricator database:
$ select * from phabricator_repository.repository_pullevent;
500 | {"response.message":"Error 1: sudo: a password is required\n"}
Can any one help me out to understand the issues from repository_pullevents and daemons.log file.
thanks in advance!
i resolved the problem with sudo, by changing the user running apache and adding the symlink created for git-http-backened in sudoers for the apache user.
and the problem with repository bad HEAD revision was resolved by making the first commit from a client machine.

sbt-release plugin logs git push as error, despite it succeeding

I am using the sbt-release plugin.
The process seems to work, however, sbt logs the final release step, pushChanges as error. Ideally, only actual errors are logged to error output as it can confuse the automation.
Sample output here:
Push changes to the remote repository (y/n)? [y] y
[error] To git#git.mycompany.com:gsilin/s3-client.git
[error] 67277ef..a1b959f my_branch -> my_branch
[error] To git#git.mycompany.com:gsilin/s3-client.git
[error] * [new tag] v0.1.8 -> v0.1.8
my_branch in this case is not the master branch (as I'm testing this process on my own branch before it goes to master), could that be the issue?
I don't know if something's changed in the latest version, but before sbt-release was warning you before this push step, that git sends it's info on stderr and so it will be shown with error messages in sbt although the process goes perfectly fine. So it's ok, don't worry.

Resources