[hugin-ptx] hg unwanted pushes to trunk

[Harry van der Wolf]

On OSX we do have a couple of text files in the build which need to be changed to users own specific paths before you can build with XCode.

I modified these files of course to reflect my own build environment.

HG now commits and pushes these "changes" also on commit and push.

unnecessary to say that I don't want this. How can I prevent this?

Note: my work-around is now to copy the standard "SetEnv-universal.txt" and "SetEnv-leopard.txt" to "mySetEnv-universal.txt" and "mySetEnv-leopard.txt" and use the latter two.

Harry

--
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[T. Modes]

Hi Harry,

On 24 Mai, 12:51, Harry van der Wolf <hvdw...@gmail.com> wrote:
> On OSX we do have a couple of text files in the build which need to be
> changed to users own specific paths before you can build with XCode.
>
> I modified these files of course to reflect my own build environment.
>
> HG now commits and pushes these "changes" also on commit and push.
>
> unnecessary to say that I don't want this. How can I prevent this?
>

I don't know, if this works in your case, but you can create a
file .hgignore next to the .hg folder which contains files which are
ignored by mercurial.
See http://mercurial.selenic.com/wiki/.hgignore
But I think, this will fail if you make indentional changes to these
files (Maybe then you have to delete/rename .hgignore, commit the
changes and then rename the file back to .hgignore)

My .hgignore contains the following lines (created by TortoiseHG):
glob:rev.txt
glob:.hgignore

It ignores the created rev.txt, which contains the revision number,
and also the .hgignore file itself.

Maybe there is better solution, but this works for me

Thomas

[Yuv]

Hoi Harry

On May 24, 6:51 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> On OSX we do have a couple of text files in the build which need to be
> changed to users own specific paths before you can build with XCode.
>
> I modified these files of course to reflect my own build environment.
>
> HG now commits and pushes these "changes" also on commit and push.
>
> unnecessary to say that I don't want this. How can I prevent this?
>
> Note: my work-around is now to copy the standard "SetEnv-universal.txt" and
> "SetEnv-leopard.txt" to "mySetEnv-universal.txt" and "mySetEnv-leopard.txt"
> and use the latter two.

Does `hg forget <PATH/TO/FILE>` work for your situation?

I am not sure what the intended result is.

If you want to keep general files in the repo and have user-specific
files used for the build process, I would suggest integrating this in
the build process, e.g. with CMake's keyword substitution like I did
for Windows, e.g. with the file hugin/platforms/windows/installer/
hugin_release.iss - what is in @...@ is replaced by CMake when setting
up the project.

Yuv

[Yuv]

Hallo Thomas,

On May 24, 8:00 am, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> I don't know, if this works in your case, but you can create a
> file .hgignore next to the .hg folder which contains files which are
> ignored by mercurial.
> Seehttp://mercurial.selenic.com/wiki/.hgignore

.hgignore is global and pushed/pulled across repositories, so
your .hgignore will go to SourceForge at the next push, and from there
to me, Harry, and others at our next pull.

> My .hgignore contains the following lines (created by TortoiseHG):
> glob:rev.txt
> glob:.hgignore

makes sense globally. We may want to add patterns like
*.bak$
*~$

to avoid unintentionally addition of editor backup files.

If you want to ignore something on a per-user basis (i.e. locally
only), you need to reference a file in your ~/.hgrc (or
<repo>/.hg/.hgrc) file in the "ignore" entry of the [ui] section, e.g.
[ui]
...
ignore = ~/.hgignore_hugin

and edit the file (.hgignore_hugin in this case) with the same syntax
as .hgignore

http://www.selenic.com/mercurial/hgignore.5.html
http://www.selenic.com/mercurial/hgrc.5.html

Yuv

[Harry van der Wolf]

2010/5/24 Yuv <goo...@levy.ch>

Does `hg forget <PATH/TO/FILE>` work for your situation?
 

I am not sure what the intended result is.

I'll give it a try next time.
 

If you want to keep general files in the repo and have user-specific
files used for the build process, I would suggest integrating this in
the build process, e.g. with CMake's keyword substitution like I did
for Windows, e.g. with the file hugin/platforms/windows/installer/
hugin_release.iss - what is in @...@ is replaced by CMake when setting
up the project.

Yuv

That's exactly the problem here. It is for the XCode build. These build files need to be changed manually but only once. It can't be done during the process or interactively.

I have already thought of another work-around, like renaming them to .org files and let the user change them and save as .txt (and one line extra in the wiki and the readme). In that case the .org files are part of the repo and the user/builder can have whatever he/she likes. I want to think about it further before implementing it.

Harry

[T. Modes]

Hi Yuv,

> .hgignore is global and pushed/pulled across repositories, so
> your .hgignore will go to SourceForge at the next push, and from there
> to me, Harry, and others at our next pull.
>

You are wrong. I did already some commits and my .hgignore did not
gone to sf. Cause: I added also .hgignore to .hgignore
TortoiseHG added the entries to the file. So I assumed, it would be
the right place.

Concerning files going to repository: By using a GUI it is really
straightforward to control which files/changes go into the repository
and which changes remain in the local copy. Therefore I prefer using a
GUI because it allows me finer control about the commits than doing
all on the command line.

> If you want to ignore something on a per-user basis (i.e. locally
> only), you need to reference a file in your ~/.hgrc (or
> <repo>/.hg/.hgrc) file in the "ignore" entry of the [ui] section, e.g.

There is no ~/.hgrc file on windows. It's called mercurial.ini ;-)
But in the repository it's .hg/hgrc (without point). So this setting
stuff is very confusing. Some settings can be changed inside
TortoiseHG (as a global setting and as a repository setting). But the
ignore switch is not included. When I selected to ignore the files,
the .hgignore file was created.

Thomas

[Yuval Levy]

Hi Thomas,

On May 24, 2010 10:56:03 am T. Modes wrote:
> > .hgignore is global and pushed/pulled across repositories, so
> > your .hgignore will go to SourceForge at the next push, and from there
> > to me, Harry, and others at our next pull.
>
> You are wrong. I did already some commits and my .hgignore did not
> gone to sf. Cause: I added also .hgignore to .hgignore
> TortoiseHG added the entries to the file. So I assumed, it would be
> the right place.

Nobody is wrong. The intended use by Hg is for .hgignore to be global / in
the repository and thus revision managed. By adding .hgignore to .hgignore
you defeated the purpose of .hgignore and found another way to implement user-
specific ignore lists.

Please remove .hgignore from your .hgignore and commit - the ignores you
listed are all useful for all Windows users.

> Concerning files going to repository: By using a GUI it is really
> straightforward to control which files/changes go into the repository
> and which changes remain in the local copy. Therefore I prefer using a
> GUI because it allows me finer control about the commits than doing
> all on the command line.

Sure, I have not found an equivalent for TortoiseHG in Linux yet. I have not
bothered to search. I can see that a good GUI like TortoiseHG has many
advantages over the command line tools. I am already using hg view (which is
kind of a read-only GUI) as the most efficient way IMHO to get an overview.

> > If you want to ignore something on a per-user basis (i.e. locally
> > only), you need to reference a file in your ~/.hgrc (or
> > <repo>/.hg/.hgrc) file in the "ignore" entry of the [ui] section, e.g.
>
> There is no ~/.hgrc file on windows. It's called mercurial.ini ;-)
> But in the repository it's .hg/hgrc (without point). So this setting
> stuff is very confusing. Some settings can be changed inside
> TortoiseHG (as a global setting and as a repository setting). But the
> ignore switch is not included. When I selected to ignore the files,
> the .hgignore file was created.

sorry for the confusion, my mistake to put the dot in front of the hgrc file
inside the repository.

to my knowledge, there are two places for settings:

USER-specific settings are in ~/.hgrc or, as you point out for Windows in
mercurial.ini (which directory is it store into?)

REPOSITORY-specific settings are in <REPO>/.hg/hgrc

I don't know if/how TortoiseHg edits the hgrc (or mercurial.ini) file; nor
whether it does it the way the Mercurial people intend.

I do know that if you add to the [ui] section of an hgrc file a line saying

ignore = /path/to/special_ignore_file

you can have in that special_ignore_file the same kind of ignore directives as
in .hgignore and it has the same syntax.

to avoid confusion, we should put in <REPO>/.hgignore only things that are
globally valid for everybody; and put user specific ignores outside of it.

Yuv

[Yuval Levy]

On May 24, 2010 10:55:52 am Harry van der Wolf wrote:
> I have already thought of another work-around, like renaming them to .org
> files and let the user change them and save as .txt (and one line extra in
> the wiki and the readme). In that case the .org files are part of the repo
> and the user/builder can have whatever he/she likes. I want to think about
> it further before implementing it.

makes sense to me. then you can add the .txt files to the global .hgignore.

users pull the .org files. copy/rename to .txt and edit for the local build
process.

edits for the global build process, if necessary, are edited by power users
like you in the .org files.

when committing and pushing, the .txt files are ignored but not the .org
files.

Yuv

[T. Modes]

Hi Yuv,

> Please remove .hgignore from your .hgignore and commit - the ignores you
> listed are all useful for all Windows users.
>

Already done with your commit.

> Sure, I have not found an equivalent for TortoiseHG in Linux yet.  I have not
> bothered to search.  I can see that a good GUI like TortoiseHG has many
> advantages over the command line tools.  I am already using hg view (which is
> kind of a read-only GUI) as the most efficient way IMHO to get an overview.
>

TortoiseHg runs also on linux (at least on Gnome/Nautilus).

> I don't know if/how TortoiseHg edits the hgrc (or mercurial.ini) file; nor
> whether it does it the way the Mercurial people intend.
>

In TortoiseHg you can select whether you want to change the global
user settings or the repositories settings. Depending on which you
selected the corresponding file gets changed.

> I do know that if you add to the [ui] section of an hgrc file a line saying
>
> ignore = /path/to/special_ignore_file
>

Good to know, thats no directly accessable by TortoiseHg GUI.

> to avoid confusion, we should put in <REPO>/.hgignore only things that are
> globally valid for everybody; and put user specific ignores outside of it.

Ok.

Thomas

[Yuval Levy]

Thanks, Thomas.

On May 24, 2010 12:25:59 pm T. Modes wrote:
> TortoiseHg runs also on linux (at least on Gnome/Nautilus).

I've long abandoned Gnome and on Linux my favorite desktop is KDE, which I
strongly recommend to users who do not like to be dumbed-down.

Yuv