largefiles, hg addremove does not want to remove ...

i tried to remove a small xml file out of the repository on windows,
and addremove does not do it. could this be a bug?

$ del conf\test.xml

$ hg st
! conf\test.xml

$ hg addremove conf\test.xml
abort: minimum size for largefiles must be specified

in the userhome mercurial.ini, and in .hg/hgrc, there is:
[largefiles]
minsize = 1

btw, hg rm removes the file without error.

rupert.

Changes in 2.1 for status code for pull requests

(BTW, if this should be on the developer mailing list, let me know)

When I updated from Mercurial 2.0.2 to 2.1, I ran into a problem with
Python's pip tool for installing packages, and tracked it down to a
change in how Mercurial reports exit values in changeset
16039:093b75c7b44b: "pull: return 1 when no changes found".  I wonder
about the reasoning for this as it seems to have conflated two
different situations with an identical exit codes:

1. no changes found or
2. update had unresolved files

These two things seem quite different to me. The first implies a clean
repository (even if there's no changes), where-as the second implies a
problem. This appears conflicts with standard UNIX exit codes, which
have historically used 0 to mean "OK" and other values for errors or
conditions that need to be responded to. In this situation, however,
"no changes" don't require any kind of response. As a point of
reference, git returns 0 for "no changes".

Looking at the response codes for various Mercurial commands:

COMMAND     RETURN 0                    RETURN 1
---------------------------------------------------------------------------
add         Success                     ?
branch      Success                     ?
clone       Success                     ?
commit      Success                     Nothing changed [1]
copy        Success                     Error
grep        Match (success?)            Nothing found

let mercurial think merge has happened between branches

RE: Subdirectory clone

Ops, I've made some mistakes in the recipe. Here is the corrected one:

>   cd /repos
>   echo exclude subdir1 > filemap
>   echo exclude subdir2 >> filemap
>   hg convert --filemap filemap orig new
>   echo include subdir2 > filemap
>   echo rename subdir2 . >> filemap
>   hg convert --filemap filemap orig new/subdir2
>   echo include subdir1 > filemap
    echo exclude subdir1/subdir12 >> filemap
>   echo rename subdir1 . >> filemap
>   hg convert --filemap filemap orig new/subdir1
>   echo include subdir1/subdir12 > filemap
>   echo rename subdir1/subdir12 . >> filemap
>   hg convert --filemap filemap orig new/subdir1/subdir12
>   rm filemap
>   cd new/subdir1/subdir12
>   hg up
>   cd ..
>   hg up
>   echo subdir12 = subdir12 > .hgsub
>   hg add .hgsub
>   cd ..
    hg up -R subdir2
>   hg up
>   echo subdir1 = subdir1 > .hgsub
>   echo subdir2 = subdir2 > .hgsub
>   hg add .hgsub
>   hg commit -Sm "converted to subrepos"
>   cd ..
>   mv orig old
>   mv new orig

..so as you can see it is far from being automated...

regards,
Fritz

Development Software Systems
Festo Gesellschaft m.b.H.
Linzer Strasse 227
Austria - 1140 Wien

Firmenbuch Wien
FN 38435y
UID: ATU14650108

Tel: +43(1)91075-198
Fax: +43(1)91075-282
www.festo.at

Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme,
Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte
Dritte ist unzulaessig. Wir
bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses
E-Mails sind und das
Material von Ihrem Computer zu loeschen. 

This e-mail and any attachments are confidential and intended solely for the addressee. The perusal,
publication, copying or
dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not
the intended recipient of this
e-mail, please delete it and immediately notify the sender.

Subdirectory clone

Largefiles and Patches

We're interested in using Mercurial in conjunction with the largefiles 
extension for our projects. There appears to be a lack of decent code 
review tools so we are considering just passing patch archives around 
for review. Then one user (not necessarily the creator of the code) will 
apply the patch to the main repository. Very similar to Pull Requests on 
BitBucket and GitHub.

This workflow does not readily work with largefiles, because patches 
only appear to contain the SHA-1 hash, but the changes are never being 
pushed to a remote repository.

Any suggestions?

Is there any chance of recovery?

Hello,

So I screwed up, and I wondered if there's a method I haven't thought of to
get my data.  I am using Mercurial Distributed SCM (version 2.1) on Ubuntu,
and I use mercurial eclipse.  I pulled from a remote repository, and I asked
whether I wanted to merge of rebase.  I think it was trying to merge with a
changeset I backed out of long ago, but I'm not sure.  Anyway, I said merge
and it said that I had uncommitted changes that needed to be dropped to be
merged.  I had this happen the previous time I tried to pull, and what I
found is that if I said cancel and tried to commit, mercurial would not let
me because I had to merge first.....  So this time, just in case I copied
the entire hg directory to a different backup directory before I said yes to
erasing changes.  I figured, worst case I could copy the changes back from
the backup.  So when It erased my changes, I tried to undo it (using control
z) and that worked for some files but not all.  And when I went to restore
from the backup, I found the backup was changed as well.  I think it already
had erased my changes before it gave me the prompt :((.  Does mercurial keep
a record of this, and is there any recovery?  Also, what is the proper
solution to the commit, merge paradox in mercurial eclipse?

Thanks for any help,

Eric

--
View this message in context: http://mercurial.808500.n3.nabble.com/Is-there-any-chance-of-recovery-tp3724912p3724912.html
Sent from the General mailing list archive at Nabble.com.

Mercurial

clean all unregistered files?

update -C does not touch unregistered files.  The only way I know to get a 
really clean working dir is to make a new clone.  Is there another way?  Seems 
like it would be some option for update.

largefiles "hg add" not using settings in .hg/hgrc?

`hg st -v` to show if copy is not on tip