Push secret changesets
Asked Answered
H

6

12

That may look paradoxical, I know that secret changesets are meant to be private, but what if I want to backup those secret changesets?

I work with some branches in parallel and sometimes I want to push one, but not the others. To achieve that, I work in separate clones but I hate that.

So now mercurial has phases, I can make secret branches and have everything in the same repository. The problem is that between the beginning of the secret branch and its publication, I want to backup those secret changesets (I have a clone in another machine just to hold my backups in case something happens with my local repo or my machine).

Is there a way of doing that or my workflow is completly wrong?

Hanway answered 5/4, 2012 at 13:40 Comment(3)
If the main purpose of this is to perform a backup, I think pushing or using other HG commands is not the best method. Instead you should copy the entire repository clone to a backup destination.Phenocryst
@DaveInCaz to backup an entire repo for probably a few local changesets and the main repo might already have a backup strategy seems a bit much. (although for a small repo would probably be an easy solution.)Muldoon
You might exclude the .hg folder, perhaps, from your PC's backup if you knew for a fact it were redundant. Better would to be use hg share (instead of clone) to avoid the redundant disk usage in the first place. But most important is to have a reliable backup that works! So personally, I wouldn't go for a homegrown approach, I'd just backup the whole thing and move on.Phenocryst
I
3

It seems like phases are still relatively new and some workflows, such as this, don't seem to be included, yet. As of 2013-03-19, I believe the only way you can do this is manually changing the phases from secret to public.

You can use these commands from the command line:

for /f "delims=" %a in ('hg log --template "{rev} " -r "secret()"') do @set secret=%a
hg phase -d %secret%
hg push -f
hg phase -sf %secret%

This doesn't change the commits to secret on the repository you are pushing to, I tried to change the push to do this (but was unsuccessful):

hg push -f --remotecmd hg phase -sf %secret%

The commits would have to match exactly for the remote hg command to work, but I couldn't get it to change on the remote repository anyway.

============================================================

If you want to use a GUI like TortoiseHG Workbench you will have to do this all manually (change the phases in the GUI on any repositories you want to) at the moment. Sorry, and hopefully, we can find a better solution, soon!

Ironwood answered 19/3, 2013 at 20:38 Comment(1)
The --remotecmd flag is not meant for running hg phase on the server-side. It's meant to tell your local Mercurial how it should start the Mercurial server on the server-side when it connects with SSH.Delldella
E
5

No need to mark anything secret. If you only want to push one branch, use:

hg push -r REV

This will push REV and its ancestors only.

Secret is good for Mercurial patch queue revisions, since they can't be pushed anyway and it prevents a local clone from copying them.

Draft is good for tracking unpushed changes. If you still want to back them up, pushing them will flip them to Public, but you can reset them back to draft (as compared to another repository) with:

hg phase -fd 'outgoing(URL)'

(URL can be blank for the default push repo).

Euphemia answered 6/4, 2012 at 5:31 Comment(3)
The value of marking branches as secret is that it protects against accidents (like omitting the -r REV by mistake).Square
Of course, but if he wants to back them up, they can't be secret.Euphemia
Yes, it's a shame it isn't possible to force-push a secret branch.Square
I
3

It seems like phases are still relatively new and some workflows, such as this, don't seem to be included, yet. As of 2013-03-19, I believe the only way you can do this is manually changing the phases from secret to public.

You can use these commands from the command line:

for /f "delims=" %a in ('hg log --template "{rev} " -r "secret()"') do @set secret=%a
hg phase -d %secret%
hg push -f
hg phase -sf %secret%

This doesn't change the commits to secret on the repository you are pushing to, I tried to change the push to do this (but was unsuccessful):

hg push -f --remotecmd hg phase -sf %secret%

The commits would have to match exactly for the remote hg command to work, but I couldn't get it to change on the remote repository anyway.

============================================================

If you want to use a GUI like TortoiseHG Workbench you will have to do this all manually (change the phases in the GUI on any repositories you want to) at the moment. Sorry, and hopefully, we can find a better solution, soon!

Ironwood answered 19/3, 2013 at 20:38 Comment(1)
The --remotecmd flag is not meant for running hg phase on the server-side. It's meant to tell your local Mercurial how it should start the Mercurial server on the server-side when it connects with SSH.Delldella
I
2

The best approach is a combination of @mischab1's answer, @mark-tolonen's answer and aliases.

By following mischab1's answer, you make sure that pushing to your backup location will not change the phase to "public".

Second step would be to add the backup location to your repository's hgrc/paths:

[paths]
default = ...
backup = backup_location

The next step is to define a backup command via alias in the global hgrc, e.g. "bubr" (for backup current branch) or "burev" (backup current rev).

[alias]
bubr = push -b . backup
burev = push -r . backup

hg bubr or hg burev will then push the current branch/revision to the location defined as "backup" path.

Edit This still has the drawback that you could accidentally push all changes with "hg push" so defining also an hg pubr command to push the current branch and not using "hg push" per default might be helpful.

Intorsion answered 11/6, 2013 at 14:44 Comment(1)
You could probably set your "default" to point to backup, and give your real HG server a different name, like "real". Then "hg push" will simply push to backup, and you can define another alias like "hg real-push" to be "push -r . real". Thus you will never push anything to real by accident.Jaunty
P
0

This is the best I have come up with so far. I think its essentially equivalent to what you want push/pull to be able to do.

  1. Mark all the secret changesets you want to transfer as draft
  2. In the source repo run hg bundle -r last_draft_rev bundlefile.hg path\to\backup\repo
  3. In the destination repo run hg unbundle bundlefile.hg
  4. The changesets will come into the backup as DRAFT
  5. Mark the first draft changeset as secret, and all its descendants will be marked thusly

I couldn't get #2 to work if the changesets were still marked secret.

Phenocryst answered 17/11, 2017 at 19:33 Comment(0)
D
0
@echo off
rem hgfullpull_naive.cmd
setlocal
set SRC_REPO=%~f1
set DST_REPO=%~f2
set TMP_DIR=%TEMP%\%~n0.tmp
set NODES_LIST=%TMP_DIR%\%~n0.%RANDOM%.tmp

if "%SRC_REPO%"=="" exit /b 1
if "%DST_REPO%"=="" exit /b 1
if "%SRC_REPO%"=="%DST_REPO%" exit /b 1

call :ALL
del /Q "%NODES_LIST%"
endlocal
goto :eof

:ALL
    md "%TMP_DIR%"
    hg log --rev "secret()" --template "{node}\n" --repository "%SRC_REPO%" >"%NODES_LIST%" || exit /b 1
    call :CHANGE_PHASE "%SRC_REPO%" --draft
    hg pull --repository "%DST_REPO%" "%SRC_REPO%"
    call :CHANGE_PHASE "%SRC_REPO%" --secret
    call :CHANGE_PHASE "%DST_REPO%" --secret
    goto :eof

:CHANGE_PHASE 
    setlocal
    set REPO=%~1
    set PHASE=%~2
    for /F "eol=; delims= usebackq" %%i IN ("%NODES_LIST%") DO (hg phase %PHASE% --force --rev %%i --repository "%REPO%")
    endlocal
    goto :eof
Dandelion answered 27/12, 2017 at 18:7 Comment(0)
C
-1

The easiest thing to do now-days, is to mark your backup repository as non-publishing by adding the following to its hgrc config file.

[phases]
publish = False

See Mercurial's Wiki for more info.

Croatian answered 23/3, 2013 at 0:54 Comment(1)
This is only one half of the answer. The first problem is how to get the secret changesets out...Intorsion

© 2022 - 2024 — McMap. All rights reserved.