Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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",

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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:

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

> > 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

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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 >

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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,

Re: [fossil-users] update vs checkout

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)

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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

Re: [fossil-users] update vs checkout

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

[fossil-users] update vs checkout

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