When I switch between branches Fossil isn't removing files that belong to
the previous branch but not the current branch. Am I doing something wrong?
Example:
===
$ fossil new prj.fossil
project-id: 7e92eb48abd299ca1340a7bc0c86dba38097ad3e
server-id: 7efed910652f4fbceef4ec8cdcb152e7c944e7cc
I think the issue is that fossil close doesn't clear out the directory,
and fossil open I only overwrites files from the opened checkout, but does
not delete any files. So if you were to issue fossil extras my guess is
file2 would be in that list.
Tomek
On Wed, Jul 13, 2011 at 2:55 PM, Brian
On 7/13/2011 12:14 PM, Tomek Kott wrote:
I think the issue is that fossil close doesn't clear out the directory, and
fossil open I only overwrites files from the opened checkout, but does not
delete any files. So if you were to issue fossil extras my guess is file2
would be in that list.
To
Yep, that does the trick. I'd seen the update command but didn't realise
this was its purpose.
Should fossil close/open behave differently from fossil update? Is this a
bug in Fossil, or is it deliberate?
On Wed, Jul 13, 2011 at 3:20 PM, Andreas Kupries
andre...@activestate.comwrote:
On
On 7/13/2011 12:33 PM, Brian Cottingham wrote:
Yep, that does the trick. I'd seen the update command but didn't realise this
was its purpose.
Well, its purpose is to switch the current checkout/rev to any other revision,
so switching between branches is just a special case of that. With the
I believe it is deliberate with how fossil handles opening a repository full
of potentially un-versioned files. Imagine giving a fossil open of a fresh
repository in a folder with thousands of files, and finding that after the
command, all those files are gone.
Tomek
On Wed, Jul 13, 2011 at 3:33
On Wed, Jul 13, 2011 at 3:33 PM, Brian Cottingham spiffyt...@gmail.comwrote:
Should fossil close/open behave differently from fossil update? Is this a
bug in Fossil, or is it deliberate?
The behavior is deliberate. I'd understand what you are expecting from
close.
My recommendation is
That would be helpful. I got the idea to use 'close' from section 4.4.4 of
the fossil book, which indicates branches should be checked out by using
'open'. I thought to myself, how could I open it if it is not first
closed?, and thus my confusion was born.
On Wed, Jul 13, 2011 at 3:45 PM,
On 7/13/2011 3:45 PM, Richard Hipp wrote:
My recommendation is that you never use the close command. It really
is not needed for anything. Maybe I should simply remove the close
command to avoid confusion?
Considering the number of messages we've had over time where someone was
expecting
I might suggest amending the help command to list commonly used
commands by default,
and a new switch --all that will display the uncommon ones (such as close).
-B
On Wed, Jul 13, 2011 at 2:44 PM, Joshua Paine jos...@letterblock.com wrote:
On 7/13/2011 3:45 PM, Richard Hipp wrote:
My
On 7/13/2011 5:48 PM, Brian Smith wrote:
I might suggest amending the help command to list commonly used
commands by default,
and a new switch --all that will display the uncommon ones (such as close).
Fine, I guess, but many a smart person trying to learn a new system
would use the --all
To me, open on fossil does similar work as checkout on some SCM.
--
Martin
Le 2011-07-13 à 19:13, Brian Cottingham spiffyt...@gmail.com a écrit :
I am a newbie to Fossil, and intermediate to VCS in general. I have a basic
grasp of the Fossil commands needed to accomplish various tasks,
On 7/13/2011 7:13 PM, Brian Cottingham wrote:
was wondering if some of the Fossil internals
could be refactored to not need an explicit 'open' command. I.E., Git
and SVN don't need an open command- you just cd into a repo's directory
and stuff works. Could Fossil be reworked to act similarly?
On Wed, 13 Jul 2011 19:30:08 -0400
Joshua Paine jos...@letterblock.com wrote:
On 7/13/2011 7:13 PM, Brian Cottingham wrote:
was wondering if some of the Fossil internals
could be refactored to not need an explicit 'open' command. I.E., Git
and SVN don't need an open command- you just cd
14 matches
Mail list logo
