On Sat, Apr 30, 2016 at 11:30:08PM -0600, Scott Robison wrote:
> Note that you have to merge mybranch back to trunk, otherwise all the
> changes made in mybranch will live happily over there forever. Once you
> updated to trunk, you abandoned all committed work from the other branch.
You can also
On 4/30/16, Steve Schow wrote:
>
> So both merge and update merge into the checked out workspace, they do not
> merge into a branch in the repo under any circumstances?
>
Yes. This is an important point. The "commit" command makes changes
to the repository. The "update", "merge", "add", "rm" an
On Apr 30, 2016, at 11:27 PM, Scott Robison wrote:
>
> now you're ready to merge to trunk, so
> fossil update trunk
> MISSING STEP: fossil merge mybranch
yep I definitely missed that, thank you.
> (resolve merge conflicts and test merged workspace because it is possible
> someone slipped an
Note that you have to merge mybranch back to trunk, otherwise all the
changes made in mybranch will live happily over there forever. Once you
updated to trunk, you abandoned all committed work from the other branch.
On Sat, Apr 30, 2016 at 11:27 PM, Scott Robison
wrote:
> I think that's close if
I think that's close if I understand what you want. Maybe this gets you the
rest of the way:
(start with a clean checkout)
(work on code)
fossil commit —branch mybranch
begin loop as many times as needed while working on mybranch
fossil merge trunk
(resolve merge conflicts and test merged wo
>
> On Apr 30, 2016, at 10:56 PM, Barry Arthur wrote:
>
>> The distributed/shared repository doesn't just hold trunk... it holds all
>> non-private branches too. So when your developers are ready for you to
>> review their work, they commit it to their task branch and then you
>> (remotely) c
what you’re suggesting will not work unless I turn off auto-sync. the authors
of fossil have been very influential in convincing me to leave auto sync on.
With auto sync on, then there is no way for me to remotely code review unless
they commit to their repo, which would auto sync to the main
The distributed/shared repository doesn't just hold trunk... it holds all
non-private branches too. So when your developers are ready for you to
review their work, they commit it to their task branch and then you
(remotely) checkout/update to that branch (preferably into a fresh
directory) and test
On Apr 30, 2016, at 10:19 PM, Scott Robison wrote:
>
> So, update moves your working copy to the specified (or default) version
> specified. Merge brings changes from the specified version into your working
> copy without moving your working copy.
>
I think this sounds like the key distinc
On Apr 30, 2016, at 6:55 PM, Richard Hipp wrote:
>
> Here you want "fossil update trunk" or "fossil checkout trunk" (They
> are the same thing here because you have not made any local changes
> since the last commit) followed by "fossil merge my branch”.
Yes I understand checkout will stomp o
I'm not an expert, but let me see if I can explain.
Given the current state of your working copy, "update version" will merge
the changes between your current working copy and the specified version. If
you omit the version, it will use the most recent version on your current
branch. If you specify
On Apr 30, 2016, at 6:55 PM, Richard Hipp wrote:
> On 4/30/16, Steve Schow wrote:
>>
>> So in some ways this seems that when update is called in this “non-standard”
>> way, its a bit more like a “merge”.
>
> (1) This way isn't "non-standard". It is the usual use-case for "update”.
wait now
On Apr 30, 2016, at 6:55 PM, Scott Robison wrote:
>
> No. If you are on mybranch and you have uncommitted changes, and you run
> update trunk, your changes will not be committed to mybranch (effectively
> they will be reverted) and then they will be automatically applied to your
> working co
On Sat, Apr 30, 2016 at 6:47 PM, Steve Schow wrote:
> Merge conflicts are possible ANY time someone else edits a file and
> commits it to the trunk while you have been working on a feature branch
> rather then the trunk for a while. Lots of times, the software can merge
> without conflicts, but
On 4/30/16, Steve Schow wrote:
>
> So in some ways this seems that when update is called in this “non-standard”
> way, its a bit more like a “merge”.
(1) This way isn't "non-standard". It is the usual use-case for "update".
(2) Yes, "update" and "merge" are very similar
Let your current check-o
Merge conflicts are possible ANY time someone else edits a file and commits it
to the trunk while you have been working on a feature branch rather then the
trunk for a while. Lots of times, the software can merge without conflicts,
but sometimes no. And me personally I actually prefer to visua
Make that "fossil status or changes or extras or some combination thereof".
On Apr 30, 2016 6:32 PM, "Scott Robison" wrote:
>
> On Apr 30, 2016 6:00 PM, "Steve Schow" wrote:
> >
> > I forgot one step in this process I want:
> >
> >
> > On Apr 30, 2016, at 5:56 PM, Steve Schow wrote:
> >
> > >
>
On Apr 30, 2016 6:00 PM, "Steve Schow" wrote:
>
> I forgot one step in this process I want:
>
>
> On Apr 30, 2016, at 5:56 PM, Steve Schow wrote:
>
> >
> >
> > fossil checkout trunk
> > (work on code)
> > fossil commit —branch mybranch
> > (work on more code)
> > fossil commit
> > (code review)
I forgot one step in this process I want:
On Apr 30, 2016, at 5:56 PM, Steve Schow wrote:
>
>
> fossil checkout trunk
> (work on code)
> fossil commit —branch mybranch
> (work on more code)
> fossil commit
> (code review)
> fossil update trunk -n
> (resolve merge conflicts when they rarely oc
On Apr 30, 2016, at 5:01 AM, Richard Hipp wrote:
>
> Your current check-out and VERSION will have a common ancestor X.
> Fossil finds all the differences between X and the current check-out,
> then applies those differences to VERSION.
So in some ways this seems that when update is called in t
On 4/30/16, Steve Schow wrote:
>
> what happens if an update VERSION is specified that is not a descendant of
> the node we checked out from? What if the VERSION is on a completely
> different branch?
Your current check-out and VERSION will have a common ancestor X.
Fossil finds all the differen
On Sat, Apr 30, 2016 at 6:23 AM, Steve Schow wrote:
> More Noob questions.
>
> Trying to understand the subtle difference between the checkout command
> and update. is it fair to say that checkout will stomp over the top of the
> current working checkout area with the repo version you checkout f
More Noob questions.
Trying to understand the subtle difference between the checkout command and
update. is it fair to say that checkout will stomp over the top of the current
working checkout area with the repo version you checkout from, while the update
command will merge the changes into th
23 matches
Mail list logo