mercurial for dummies (newbies), remote heads etc

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

mercurial for dummies (newbies), remote heads etc

Uwe Brauer

Hi

I would like to ask for advice.

I do collaborate using mercurial but mostly with single users and that
works reasonable well, even given that the other person does not really
understand mercurial.

Now because of coronovirus I have forced with six colleagues to
collaborate and proposed mercurial.

Well two problems/question occur

    1. They did not take the time to learn the basic so they got
       confused when some pushes got refused, because of remote
       anonymous heads (I did not tell them the force option). I tried
       to explain the merge command but it did not really work out,
       maybe I should have told them about the fetch command, but if
       there is a conflicting merge, thinks can get worse.

       a. So I thought have having used named branches (one collaborator
          one branch), and I do the merge, but sooner or later similar
          problems occur.

    2. What would you guys have proposed?

    3. I wonder how git deals with this situation, you want to push, but
       there is already a commit (so in mercurial you would pull and
       merge) does git do this automatically?

Thanks

Uwe Brauer

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: mercurial for dummies (newbies), remote heads etc

Marcin Kasperski-2

>     2. What would you guys have proposed?

Teach them merge. But actually make them do it a few times, so they are
no longer afraid. And make sure they have kdiff3 installed and
configured as default merge tool.

>     3. I wonder how git deals with this situation, you want to push, but
>        there is already a commit (so in mercurial you would pull and
>        merge) does git do this automatically?

In git you must make named branch before commiting. Plus it tries to
rebase when you pull (sometimes with sad effects…).

I strongly doubt people who find merge difficult would find git easier.
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

RE: mercurial for dummies (newbies), remote heads etc

Becker, Mischa J-2
In reply to this post by Uwe Brauer
Back when I was first learning mercurial I found the Hg Init tutorial very clear & helpful in how it explained working with others and merges etc.  It's gone now but you can still see it in the Internet Archive if you're interested.
https://web.archive.org/web/20180926172759/http://hginit.com/

My only other suggestion, if your collaborators are willing, is to use TorgoiseHg instead of the command line.  I find it's interface and graphical log a lot easier to read & understand than hg log -G.   And it has a console window for when you still want to type commands or read hg help.

Mischa Becker

> -----Original Message-----
> From: Uwe Brauer
> Sent: Thursday, May 28, 2020 11:32 AM
> Subject: mercurial for dummies (newbies), remote heads etc
>
> Hi
>
> I would like to ask for advice.
>
> I do collaborate using mercurial but mostly with single users and that works
> reasonable well, even given that the other person does not really understand
> mercurial.
>
> Now because of coronovirus I have forced with six colleagues to collaborate
> and proposed mercurial.
>
> Well two problems/question occur
>
>     1. They did not take the time to learn the basic so they got
>        confused when some pushes got refused, because of remote
>        anonymous heads (I did not tell them the force option). I tried
>        to explain the merge command but it did not really work out,
>        maybe I should have told them about the fetch command, but if
>        there is a conflicting merge, thinks can get worse.
>
>        a. So I thought have having used named branches (one collaborator
>           one branch), and I do the merge, but sooner or later similar
>           problems occur.
>
>     2. What would you guys have proposed?
>
>     3. I wonder how git deals with this situation, you want to push, but
>        there is already a commit (so in mercurial you would pull and
>        merge) does git do this automatically?
>
> Thanks
>
> Uwe Brauer
>
> _______________________________________________
> Mercurial mailing list
> [hidden email]
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .mercurial-
> scm.org%2Fmailman%2Flistinfo%2Fmercurial&data=02%7C01%7Cmisch
> a.becker%40kroger.com%7C80944cb127924c416e3608d80336fc9e%7C8331e
> 14a91344288bf5a5e2c8412f074%7C0%7C1%7C637262882000396652&s
> data=3KLuavABwIpIhQVULhSRax16JkVr6rp0ZTA87eR6N6Y%3D&reserve
> d=0

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: mercurial for dummies (newbies), remote heads etc

Uwe Brauer
In reply to this post by Marcin Kasperski-2
>>> "MK" == Marcin Kasperski <[hidden email]> writes:

   >> 2. What would you guys have proposed?

   > Teach them merge. But actually make them do it a few times, so they are
   > no longer afraid. And make sure they have kdiff3 installed and
   > configured as default merge tool.

   >> 3. I wonder how git deals with this situation, you want to push, but
   >> there is already a commit (so in mercurial you would pull and
   >> merge) does git do this automatically?

   > In git you must make named branch before commiting. Plus it tries to
   > rebase when you pull (sometimes with sad effects…).

   > I strongly doubt people who find merge difficult would find git easier.
Right I just checked for example

https://devconnected.com/how-to-push-git-branch-to-remote/

The error message is however better than the one provided by mercurial
it gives a hint.


My colleagues swear in Dropbox, the number manually either files or
directories, which is very cumbersome. However, I wonder how they avoid
conflicting errors. It sound that they following subversions idea.

I never used subversion, (I used RCS, a bit of CVS and then mercurial)

I had a quick look in subversion's manual, the branching model is just
terrible. Now idea why it is still widely used.

Uwe

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mercurial for dummies (newbies), remote heads etc

Uwe Brauer
In reply to this post by Marcin Kasperski-2
>>> "MK" == Marcin Kasperski <[hidden email]> writes:

   >> 2. What would you guys have proposed?

   > Teach them merge. But actually make them do it a few times, so they are
   > no longer afraid. And make sure they have kdiff3 installed and
   > configured as default merge tool.

   >> 3. I wonder how git deals with this situation, you want to push, but
   >> there is already a commit (so in mercurial you would pull and
   >> merge) does git do this automatically?

   > In git you must make named branch before commiting. Plus it tries to
   > rebase when you pull (sometimes with sad effects…).

On  a second thought: maybe I should tell them to add a bookmark to the
changeset they want to push,

    1. they push,

    2. I pull, merge and push back

I honestly don't like bookmarks, but maybe this is a way avoid their confusion,

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mercurial for dummies (newbies), remote heads etc

Harald Klimach
Hi,

>     1. they push,
>
>     2. I pull, merge and push back

If you don't want them to bother with the merging, why have them push at
all? Just pull from their repositories, and push necessary merges back.

If this is not possible either let them send the changesets by mail then
tell them to pull from your main repository again after your merge, or
create "forks" for them at places, where they can push to (one for each)
and you can pull from and push back again.

Best,
Harald
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: mercurial for dummies (newbies), remote heads etc

Uwe Brauer
>>> "HK" == Harald Klimach <[hidden email]> writes:

   > Hi,
   >> 1. they push,
   >>
   >> 2. I pull, merge and push back

   > If you don't want them to bother with the merging, why have them push at
   > all? Just pull from their repositories, and push necessary merges back.

   > If this is not possible either let them send the changesets by mail then
   > tell them to pull from your main repository again after your merge, or
   > create "forks" for them at places, where they can push to (one for each)
   > and you can pull from and push back again.

Yeah but then I could return almost to sending email with changes
anyway, which is what I don't want.

Most likely the bookmark solution is an option, not that I am very
convinced by it......

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[Dropbox without pushes] (was: mercurial for dummies (newbies), remote heads etc)

Uwe Brauer
In reply to this post by Harald Klimach
>>> "HK" == Harald Klimach <[hidden email]> writes:

   > Hi,
   >> 1. they push,
   >>
   >> 2. I pull, merge and push back

   > If you don't want them to bother with the merging, why have them push at
   > all? Just pull from their repositories, and push necessary merges back.

   > If this is not possible either let them send the changesets by mail then
   > tell them to pull from your main repository again after your merge, or
   > create "forks" for them at places, where they can push to (one for each)
   > and you can pull from and push back again.

Usually it is said, one should not use dropbox as a repository, in the
sense that pushes and pulls wouldn't work.

But would the following work.

I move my local repository to my local Dropbox folder which is
synchronized with my real Dropbox account.

My colleagues would copy and modify the Dropbox folder and I would try
periodically try to commit their changes.

I could also use the share extension. I tried that once or twice and
found its behavior confusing.

Any comments?

Uwe Brauer

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Dropbox without pushes]

Cesar Mena-2
Uwe Brauer <[hidden email]> writes:

>>>> "HK" == Harald Klimach <[hidden email]> writes:
>
>    > Hi,
>    >> 1. they push,
>    >>
>    >> 2. I pull, merge and push back
>
>    > If you don't want them to bother with the merging, why have them push at
>    > all? Just pull from their repositories, and push necessary merges back.
>
>    > If this is not possible either let them send the changesets by mail then
>    > tell them to pull from your main repository again after your merge, or
>    > create "forks" for them at places, where they can push to (one for each)
>    > and you can pull from and push back again.
>
> Usually it is said, one should not use dropbox as a repository, in the
> sense that pushes and pulls wouldn't work.
>
> But would the following work.
>
> I move my local repository to my local Dropbox folder which is
> synchronized with my real Dropbox account.
>
> My colleagues would copy and modify the Dropbox folder and I would try
> periodically try to commit their changes.
>
> I could also use the share extension. I tried that once or twice and
> found its behavior confusing.
>
> Any comments?

hi,

use bundles.

1. have the dropbox repo be pull only for your colleagues.

2. to commit their changes you (or they) could create bundles[1] and
move them to dropbox.

  a. hg ci -m "colleague changes"
  b. hg bundle -f colleague.bundle.1 --base uwe-master
  c. cp colleague.bundle.1 ~/Dropbox/incoming/

3. then you, as the sole committer, inspect and apply the bundles at
your discretion.  ie, hg pull colleague.bundle.1

you could even drive bundle creation from a tag (uwe-master above) from
the main repository.

if i may suggest, keep a non-dropbox copy of the repository on your
computer and do your work there. then push to the dropbox one when you
are ready to share.

--

[1] bundles preserve all revision history and can deal with branches.
see hg help bundle.
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [Dropbox without pushes]

Cesar Mena-2
cesar mena <[hidden email]> writes:

> Uwe Brauer <[hidden email]> writes:
>
>>>>> "HK" == Harald Klimach <[hidden email]> writes:
>>
>>    > Hi,
>>    >> 1. they push,
>>    >>
>>    >> 2. I pull, merge and push back
>>
>>    > If you don't want them to bother with the merging, why have them push at
>>    > all? Just pull from their repositories, and push necessary merges back.
>>
>>    > If this is not possible either let them send the changesets by mail then
>>    > tell them to pull from your main repository again after your merge, or
>>    > create "forks" for them at places, where they can push to (one for each)
>>    > and you can pull from and push back again.
>>
>> Usually it is said, one should not use dropbox as a repository, in the
>> sense that pushes and pulls wouldn't work.
>>
>> But would the following work.
>>
>> I move my local repository to my local Dropbox folder which is
>> synchronized with my real Dropbox account.
>>
>> My colleagues would copy and modify the Dropbox folder and I would try
>> periodically try to commit their changes.
>>
>> I could also use the share extension. I tried that once or twice and
>> found its behavior confusing.
>>
>> Any comments?
>
> hi,
>
> use bundles.
>
> 1. have the dropbox repo be pull only for your colleagues.
>
> 2. to commit their changes you (or they) could create bundles[1] and
> move them to dropbox.
>
>   a. hg ci -m "colleague changes"
>   b. hg bundle -f colleague.bundle.1 --base uwe-master
>   c. cp colleague.bundle.1 ~/Dropbox/incoming/
>
> 3. then you, as the sole committer, inspect and apply the bundles at
> your discretion.  ie, hg pull colleague.bundle.1
>
> you could even drive bundle creation from a tag (uwe-master above) from
> the main repository.
>
> if i may suggest, keep a non-dropbox copy of the repository on your
> computer and do your work there. then push to the dropbox one when you
> are ready to share.
>
> --
>
> [1] bundles preserve all revision history and can deal with branches.
> see hg help bundle.

hi again,

come to think of it, it can be simpler than what i suggested in:
https://www.mercurial-scm.org/pipermail/mercurial/2020-May/052000.html.

it's basically the same as the bundle idea, but we are letting mercurial
do its thing!

the strategy would be to keep a repo per colleague in dropbox and have
them push/pull there. then you can merge onto a central repo that would
be in dropbox as well and accessible as pull only to your colleagues.

but once again, if i may, keep a non-dropbox copy of the repository on
your computer and do your work there. then push to the dropbox one when
you are ready to share.  this way, should the dropbox repo become
corrupted, you can always re-clone the non-dropbox one.

cheers!



_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [Dropbox without pushes]

Uwe Brauer

Hi

Thanks for your mail
   > cesar mena <[hidden email]> writes:

   > hi again,

   > come to think of it, it can be simpler than what i suggested in:
   > https://www.mercurial-scm.org/pipermail/mercurial/2020-May/052000.html.

   > it's basically the same as the bundle idea, but we are letting mercurial
   > do its thing!

   > the strategy would be to keep a repo per colleague in dropbox and have
   > them push/pull there. then you can merge onto a central repo that would
   > be in dropbox as well and accessible as pull only to your colleagues.

   > but once again, if i may, keep a non-dropbox copy of the repository on
   > your computer and do your work there. then push to the dropbox one when
   > you are ready to share.  this way, should the dropbox repo become
   > corrupted, you can always re-clone the non-dropbox one.


So if I understand that correctly: say in my dropobox account there will be

    1. Collaboration/colleague1

    2. Collaboration/colleague2

    3. Collaboration/main

    4. In my machine a cloned main repo.

Then the workflow is.

    1. Colleague  pushes only to colleague 1 etc

    2. Colleague pull only from main


So this is basically the same, as everybody having his own named branch, say
in bitbucket (soon helix)

I have to think about it. Thanks for the proposal.

Regards

Uwe


_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Dropbox without pushes]

Cesar Mena-2
Uwe Brauer <[hidden email]> writes:

> Hi
>
> Thanks for your mail
>    > cesar mena <[hidden email]> writes:
>
>    > hi again,
>
>    > come to think of it, it can be simpler than what i suggested in:
>    > https://www.mercurial-scm.org/pipermail/mercurial/2020-May/052000.html.
>
>    > it's basically the same as the bundle idea, but we are letting mercurial
>    > do its thing!
>
>    > the strategy would be to keep a repo per colleague in dropbox and have
>    > them push/pull there. then you can merge onto a central repo that would
>    > be in dropbox as well and accessible as pull only to your colleagues.
>
>    > but once again, if i may, keep a non-dropbox copy of the repository on
>    > your computer and do your work there. then push to the dropbox one when
>    > you are ready to share.  this way, should the dropbox repo become
>    > corrupted, you can always re-clone the non-dropbox one.
>
>
> So if I understand that correctly: say in my dropobox account there will be
>
>     1. Collaboration/colleague1
>
>     2. Collaboration/colleague2
>
>     3. Collaboration/main
>
>     4. In my machine a cloned main repo.
>
> Then the workflow is.
>
>     1. Colleague 1 pushes only to colleague 1 etc
>
>     2. Colleague pull only from main

you said it better :)

> So this is basically the same, as everybody having his own named branch, say
> in bitbucket (soon helix)

yes, with the added benefit colleagues don't write into other colleagues
backends, lessening the chance for dropbox conflicts.

> I have to think about it. Thanks for the proposal.

good luck!

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [Dropbox without pushes]

Uwe Brauer

   > Uwe Brauer <[hidden email]> writes:

   > you said it better :)


   > yes, with the added benefit colleagues don't write into other colleagues
   > backends, lessening the chance for dropbox conflicts.

No I mean if I stick to named branches, than we can stay with bitbucket,
my colleagues very surprised, even annoyed by the message

«you cannot push because of anonymous heads»


Without pushing problems, people are ok with mercurial.

That is why dropbox was mentioned.

However this is self-deception at its finest.

The point is, and I think this is a general phenomena, people in a
collaboration think they are working strictly sequential, while in fact
they don't. Because if they worked sequential, then there would be no
anonymous heads.


Mercurial just displays an underlining merging problem, which I am
afraid a lot of people have difficulties to gasp.

And that is why I think all these dropbox solutions have un noticed
merging problems

Uwe

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Dropbox without pushes]

Cesar Mena-2
Uwe Brauer <[hidden email]> writes:

> No I mean if I stick to named branches, than we can stay with bitbucket,
> my colleagues very surprised, even annoyed by the message
>
> «you cannot push because of anonymous heads»

i see. in this case dropbox will just make everything worse for you.
you now have the "push" problem, and the possibility of dropbox
conflicts on mercurial state (the stuff under .hg/) files.

> Without pushing problems, people are ok with mercurial.

see below for using -f.

> That is why dropbox was mentioned.
>
> However this is self-deception at its finest.

:)

> The point is, and I think this is a general phenomena, people in a
> collaboration think they are working strictly sequential, while in fact
> they don't. Because if they worked sequential, then there would be no
> anonymous heads.
>
>
> Mercurial just displays an underlining merging problem, which I am
> afraid a lot of people have difficulties to gasp.
>
> And that is why I think all these dropbox solutions have un noticed
> merging problems

what about having your colleagues always push with -f (hg push -f), and
then the onus is on you to resolve all merges?

cheers!
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [Dropbox without pushes]

Uwe Brauer
>>> "cm" == cesar mena <[hidden email]> writes:

   > :)

   >> The point is, and I think this is a general phenomena, people in a
   >> collaboration think they are working strictly sequential, while in fact
   >> they don't. Because if they worked sequential, then there would be no
   >> anonymous heads.
   >>
   >>
   >> Mercurial just displays an underlining merging problem, which I am
   >> afraid a lot of people have difficulties to gasp.
   >>
   >> And that is why I think all these dropbox solutions have un noticed
   >> merging problems

   > what about having your colleagues always push with -f (hg push -f), and
   > then the onus is on you to resolve all merges?

I know that would be the method of last resort. That might be soon
become quite messy.
An alternative would be

 hg book colleague1
 hg push -B collegue1

I have to think about it. I will try to make them aware of the merging
problem, as a pure logical one.

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mercurial for dummies (newbies), remote heads etc

Pierre-Yves David-2
In reply to this post by Uwe Brauer


On 5/28/20 8:32 PM, Uwe Brauer wrote:

>
> Hi
>
> I would like to ask for advice.
>
> I do collaborate using mercurial but mostly with single users and that
> works reasonable well, even given that the other person does not really
> understand mercurial.
>
> Now because of coronovirus I have forced with six colleagues to
> collaborate and proposed mercurial.
>
> Well two problems/question occur
>
>      1. They did not take the time to learn the basic so they got
>         confused when some pushes got refused, because of remote
>         anonymous heads (I did not tell them the force option). I tried
>         to explain the merge command but it did not really work out,
>         maybe I should have told them about the fetch command, but if
>         there is a conflicting merge, thinks can get worse.

Do you have details on what's their trouble with merge ? Do they have
trouble with the concept has a whole ? are they confused about when to
run the command ? do they have trouble with conflict resolution ? If so,
which tool to they use.

(side note: having the ability to commit and push conflict would solve
this usecase)

>         a. So I thought have having used named branches (one collaborator
>            one branch), and I do the merge, but sooner or later similar
>            problems occur.

It is not part of the standard distribution, but topic has a mode to
automatically assign a topic to any new commit. That would be
"[experimental] \n topic-mode = random-all". combined with a non
publishing repository, that would let them push their change while you
do the merging/publishing.

>      2. What would you guys have proposed?
>
>      3. I wonder how git deals with this situation, you want to push, but
>         there is already a commit (so in mercurial you would pull and
>         merge) does git do this automatically?

--
Pierre-Yves David
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: mercurial for dummies (newbies), remote heads etc

Uwe Brauer
>>> "PD" == Pierre-Yves David <[hidden email]> writes:

Hi

I only saw you response today.


   > On 5/28/20 8:32 PM, Uwe Brauer wrote:
   >> maybe I should have told them about the fetch command, but if
   >> there is a conflicting merge, thinks can get worse.

   > Do you have details on what's their trouble with merge ?

Well I think some have  still have not gasped the conceptual concept  of
merging (I will have to talk
to them), but those who have gasped it expect that the server sort out the
merging, so they push and they expect the server to do the merge, so I
guess the concept of  DVCS is alien to them and I thing that is why
subversion model was so successful [1] .
   > Do they have
   > trouble with the concept has a whole ? are they confused about when to
   > run the command ? do they have trouble with conflict resolution ? If
   > so, which tool to they use.

No I really try to to conflicting merging myself and try to spare them
that trouble.

   > (side note: having the ability to commit and push conflict would solve
   > this usecase)

   >> a. So I thought have having used named branches (one collaborator
   >> one branch), and I do the merge, but sooner or later similar
   >> problems occur.

   > It is not part of the standard distribution, but topic has a mode to
   > automatically assign a topic to any new commit. That would be
   > "[experimental] \n topic-mode = random-all". combined with a non

Wait wait I did not know about that feature, starting form which version
this feature is available?


   > publishing repository, that would let them push their change while you
   > do the merging/publishing.

I thought of topics also also, but it is my understanding that they need
evolve to be installed, and this seemed to me to complicated, since some
are using linux, some Mac some windows.

Thanks for the advice

Regards

Uwe

Footnotes:
[1]  I have never used subversion, so I really don't know, I just for
     most of the time RCS, and when I contributed to code it was CVS.
     When I thought of switching to a modern VC system, I found git
     terrible, and at first the most attractive features of mercurial
     were local revision numbers and keyword expansion, later then named branches.

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mercurial for dummies (newbies), remote heads etc

Pierre-Yves David-2


On 6/15/20 8:40 PM, Uwe Brauer wrote:

>>>> "PD" == Pierre-Yves David <[hidden email]> writes:
>
> Hi
>
> I only saw you response today.
>
>
>     > On 5/28/20 8:32 PM, Uwe Brauer wrote:
>     >> maybe I should have told them about the fetch command, but if
>     >> there is a conflicting merge, thinks can get worse.
>
>     > Do you have details on what's their trouble with merge ?
>
> Well I think some have  still have not gasped the conceptual concept  of
> merging (I will have to talk
> to them), but those who have gasped it expect that the server sort out the
> merging, so they push and they expect the server to do the merge, so I
> guess the concept of  DVCS is alien to them and I thing that is why
> subversion model was so successful [1] .
>     > Do they have
>     > trouble with the concept has a whole ? are they confused about when to
>     > run the command ? do they have trouble with conflict resolution ? If
>     > so, which tool to they use.
>
> No I really try to to conflicting merging myself and try to spare them
> that trouble.
>
>     > (side note: having the ability to commit and push conflict would solve
>     > this usecase)
>
>     >> a. So I thought have having used named branches (one collaborator
>     >> one branch), and I do the merge, but sooner or later similar
>     >> problems occur.
>
>     > It is not part of the standard distribution, but topic has a mode to
>     > automatically assign a topic to any new commit. That would be
>     > "[experimental] \n topic-mode = random-all". combined with a non
>
> Wait wait I did not know about that feature, starting form which version
> this feature is available?

I think this was implemented at the time of the sprint in dublin, so
2017 IIRC.

>     > publishing repository, that would let them push their change while you
>     > do the merging/publishing.
>
> I thought of topics also also, but it is my understanding that they need
> evolve to be installed, and this seemed to me to complicated, since some
> are using linux, some Mac some windows.

Evolve (and topic) will be shipped with Tortoise hg. On other plateform,
you can get it using `pip install --user hg-evolve`


--
Pierre-Yves David
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial