Re: [fossil-users] quick poll: do you generally use add/rm or mv

[arnoldemu]

I would use mv.

Having had bad experiences with other source control systems where you loose 
history with add/rm type commands, I would use mv to retain that.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Andy Bradford]

Thus said Andy Goth on Wed, 05 Aug 2015 10:35:56 -0500:

> Unix mv would  have renamed the directory from dir  to dir2, i.e. made
> the new  directory, moved all  files and subdirectories into  it, then
> removed the old directory.

Slight  pedantry (with  loose  definitions) here...  Only under  certain
circumstances does Unix actually move the files. If the directory rename
happens on a single filesystem, then the directory name in the directory
entry is simply  updated; even in the case where  the directory is moved
into a different  tree, it still retains the same  inode and removes the
old name  from the directory  entry and places  it into a  new directory
entry, and no files are actually moved.

To the user it might appear  that things have ``moved'' but really, just
a few  inode changes here  and there have  happened. No data  was moved,
just metadata (except when the move crosses filesystems).

I don't routinely use fossil mv so I don't know how similar its behavior
is.

Andy
-- 
TAI64 timestamp: 400055c2c0e9


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Ron W]

On Wed, Aug 5, 2015 at 4:02 PM, Warren Young  wrote:

> On Aug 5, 2015, at 9:35 AM, Andy Goth  wrote:
> >
> > It creates an empty file called dir2 and leaves dir/file alone.
>
> Okay, this isn’t an argument about proper semantics after all, it’s a bug
> report.  The behavior you’re seeing is simply wrong.
>
> I suspect the core problem is that Fossil doesn’t version directories,
> only files.  That is, there is no “fossil mkdir” command, and “mkdir foo ;
> fossil add foo” is a no-op.  I’ve run up against this several times since
> switching from Subversion.
>

True. See below.


>
> > Unix mv would have renamed the directory from dir to dir2
>
> Yes.  “fossil mv --hard” should do that, too.
>

Agreed.


>
> Instead, it should realize that the mv destination doesn’t exist, so it’s
> clearly a “rename" type mv, not a “move” mv.  So, it should call rename(2)
> on the directory entry, then record whatever it needs to in its DB to
> remember that foo2 was once called foo, and all of foo’s current contents
> are now under foo2.
>
> The contents of foo should not be touched at all.


Since Fossil doesn't track directories, during a rename/move operation, it
needs to check if the entity being renamed/moved is a directory. If so,
then every thing under the directory has to be renamed/moved.

This is because to Fossil "dir/file.c" is a file named "dir/file.c", not a
file in a directory.

How this is best implemented inside Fossil is up to the Fossil devs.

Conceptually, the command:
fossil mv dir dir2

would be equivalent to something like:
find dir -type f -print | perl -ne 's/^dir//; qx(fossil mv "dir$_"
"dir2$_");'
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Warren Young]

On Aug 5, 2015, at 9:35 AM, Andy Goth  wrote:
> 
> It creates an empty file called dir2 and leaves dir/file alone.

Okay, this isn’t an argument about proper semantics after all, it’s a bug 
report.  The behavior you’re seeing is simply wrong.

I suspect the core problem is that Fossil doesn’t version directories, only 
files.  That is, there is no “fossil mkdir” command, and “mkdir foo ; fossil 
add foo” is a no-op.  I’ve run up against this several times since switching 
from Subversion.

> Unix mv would have renamed the directory from dir to dir2

Yes.  “fossil mv --hard” should do that, too.

> i.e. made the
> new directory, moved all files and subdirectories into it, then removed
> the old directory.

If Fossil has to implement “mv” that way, it’s doing too much work, and is 
probably setting itself up for another semantic mismatch w.r.t. POSIX mv 
semantics, since that is not how POSIX mv is implemented, not even down at the 
filesystem layer.

Instead, it should realize that the mv destination doesn’t exist, so it’s 
clearly a “rename" type mv, not a “move” mv.  So, it should call rename(2) on 
the directory entry, then record whatever it needs to in its DB to remember 
that foo2 was once called foo, and all of foo’s current contents are now under 
foo2. 

The contents of foo should not be touched at all.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Ron W]

On Wed, Aug 5, 2015 at 11:35 AM, Andy Goth  wrote:
>
> Unix mv would have renamed the directory from dir to dir2, i.e. made the
> new directory, moved all files and subdirectories into it, then removed
> the old directory.
>

Actually, the directory just gets rename. And if the directory is moved,
Unix/Linux systems will create a new "link" to the directory in it's target
location, then remove the original link. The time directory contents would
have to be "physically" move is if the target location in a different file
system (what Windows would call a volume or "drive").

The reason Fossil's mv semantics differ is because Fossil is tracking files
relative to the project root. Therefore, to Fossil, "dir/file.c" is just
the name of a file. While Unix/Linux "sees" the name of a directory and the
name of a file in that directory.

Really, Fossil is only tracking "artifacts". When an artifact is a file,
it's manifest artifact has a file name attribute (for that artifact) with a
value like "dir/file.c" that means something to a Unix/Linux/other file
system. To Fossil, it's just a piece of meta data being maintained in the
repository.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Andy Goth]

On 8/5/2015 12:34 PM, Matt Welland wrote:
> On Wed, Aug 5, 2015 at 8:01 AM, Andy Goth  > wrote:
>> http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20758.html
> 
> I have had people I support run into that several times. It would be
> really excellent to be able to tell users that they can refactor the
> organisation of a project using mv, rm etc. on a branch and then merge
> it back in. Currently it can't be done so I advise people that they
> should freeze development, do the refactor, then restart development.

Have you read my follow-up emails?  This part especially:

"Looking at the merge code, I see this comment:

"Rename files that have taken a rename on P->M but which keep the same
name on P->V.  If a file is renamed on P->V only or on both P->V and
P->M then we retain the V name of the file.

"Thinking about this further, it's making more and more sense.  The
merge algorithm of working from the nearest common ancestor is built on
the assumption that everything before then has already been merged.

"That assumption does not hold in the situation given by the second
sentence of the comment quoted above."

The issue is indeed a consequence of the design of the merge algorithm.
Fixing it is going to take some thought.

You probably should not reply to this email since it's getting far off
topic.  If you can, please reply to the original thread.

> Fixing this and making mv semantics identical to Unix would be a big
> win for fossil in my opinion.

Agree.  Thankfully, mv is going in the right direction.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Matt Welland]

On Wed, Aug 5, 2015 at 8:01 AM, Andy Goth  wrote:

> On 8/4/2015 12:59 AM, Stephan Beal wrote:
> > On Mon, Aug 3, 2015 at 9:04 PM, Ross Berteig  > > wrote:
> >> And then, there will be fresh set of edge cases with subtly
> >> different behavior on Windows. And for that matter, do all versions
> >> of Unix-descendents mv have the same quirks at the edges?
> >>
> >> IMHO, fossil does a remarkable job of handling rename now. I'm not
> >> sure what the ROI is for tuning the fossil mv command further...
> >
> > fwiw: +1
>
> Maybe it's time to bump my old thread about a serious deficiency in
> renaming in combination with branching and merging.  No one has replied
> to this thread, other than myself to report on further research.
>
>
> http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20758.html


Thanks Andy for the clear articulation of that problem. I have had people I
support run into that several times. It would be really excellent to be
able to tell users that they can refactor the organisation of a project
using mv, rm etc. on a branch and then merge it back in. Currently it can't
be done so I advise people that they should freeze development, do the
refactor, then restart development. This is not something that happens all
the time but when it does it is frustrating that the refactoring can't be
done in parallel with development. Fixing this and making mv semantics
identical to Unix would be a big win for fossil in my opinion.


>
>
> --
> Andy Goth | 
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Michai Ramakers]

On 5 August 2015 at 17:35, Andy Goth  wrote:
>
> Let's take one case where Fossil and Unix disagree about mv.
>
> mkdir -p x/dir
> fossil new x.fossil
> cd x
> f open ../x.fossil
> echo hello > dir/file
> f addremove
> f mv -hard dir dir2
>
> The last command prints:
>
> RENAME dir dir2
> MOVED_FILE /home/andy/x/dir
>
> It creates an empty file called dir2 and leaves dir/file alone.  It also
> doesn't change the change list, which still says "ADDED dir/file".

This is (probably) fixed very recently in a branch:
http://fossil-scm.org/index.html/timeline?r=mvHardDirFix&nd&c=2015-07-29+18%3A44%3A10&n=200

(I didn't know you could omit one hyphen from long options btw.)

Michai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Andy Goth]

On 8/4/2015 2:02 PM, Warren Young wrote:
> On Aug 3, 2015, at 4:35 PM, Andy Goth  wrote:
>> On 8/3/2015 3:37 PM, Warren Young wrote:
>>> On Aug 3, 2015, at 12:49 PM, Andy Goth  wrote:
 Any plans to bring them in sync?
>>>
>>> We had a long thread about it months ago:
>>
>> Pretty sure he was talking about whether or not mv and rm should
>> touch the checkout files, not about whether their semantics should be
>> made to match those of the like-named Unix commands.
> 
> I don’t see the distinction.

When I say "semantics" I'm explicitly *not* talking about whether or not
Fossil touches the disk files.  I'm talking about how Fossil interprets
user intent, irrespective of whether it does its work to disk files, the
list of pending changes, or a dry run/debug printout.

Let's take one case where Fossil and Unix disagree about mv.

mkdir -p x/dir
fossil new x.fossil
cd x
f open ../x.fossil
echo hello > dir/file
f addremove
f mv -hard dir dir2

The last command prints:

RENAME dir dir2
MOVED_FILE /home/andy/x/dir

It creates an empty file called dir2 and leaves dir/file alone.  It also
doesn't change the change list, which still says "ADDED dir/file".

Unix mv would have renamed the directory from dir to dir2, i.e. made the
new directory, moved all files and subdirectories into it, then removed
the old directory.

Fossil mv's handling of directories seems to have improved lately, but
it's not really worth our time to dig up old misbehaviors.  What I
describe now is current as of [1d3a80474b].

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Andy Goth]

On 8/4/2015 12:59 AM, Stephan Beal wrote:
> On Mon, Aug 3, 2015 at 9:04 PM, Ross Berteig  > wrote:
>> And then, there will be fresh set of edge cases with subtly
>> different behavior on Windows. And for that matter, do all versions
>> of Unix-descendents mv have the same quirks at the edges?
>>
>> IMHO, fossil does a remarkable job of handling rename now. I'm not
>> sure what the ROI is for tuning the fossil mv command further...
> 
> fwiw: +1

Maybe it's time to bump my old thread about a serious deficiency in
renaming in combination with branching and merging.  No one has replied
to this thread, other than myself to report on further research.

http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20758.html

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Warren Young]

On Aug 4, 2015, at 1:53 PM, Joe Mistachkin  wrote:
> 
> Warren Young wrote:
>> 
>> Fossil currently forces a two-step mv
> 
> No, it doesn't.  Fossil now has the --hard option for mv/rm.

Ah, I completely missed the announcement of that feature.

However, this feature is not available by default, as you seem to be saying, at 
least in trunk.  You must say:

 ./configure --with-legacy-mv-rm

for the mv-rm-files option to be available.  It’s documented at the bottom of 
/setup_settings, but if you configure without options, there is no UI field for 
it, and you get this on the command line:

$ fossil set mv-rm-files 1
no such setting: mv-rm-files
$ f ver
This is fossil version 1.33 [0a2ebe576d] 2015-08-03 18:35:53 UTC

Also, I’d say this configure option and the underlying C macro it defines is 
named confusingly.  I’m not “enabling legacy mode” here, I’m enabling a preview 
of a future default feature.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Joe Mistachkin]

Warren Young wrote:
>
> Fossil currently forces a two-step mv, which is different from *every
> other popular F/OSS VCS* except for CVS, and that's only because CVS
> doesn't have mv at all.
>

No, it doesn't.  Fossil now has the --hard option for mv/rm.  Also, it
can be compiled in such a way that --hard is the default.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Warren Young]

On Aug 3, 2015, at 4:35 PM, Andy Goth  wrote:
> 
> On 8/3/2015 3:37 PM, Warren Young wrote:
>> On Aug 3, 2015, at 12:49 PM, Andy Goth  wrote:
>>> On 8/3/2015 2:01 AM, Michai Ramakers wrote:
>>> 
>>> Any plans to bring them in sync?
>> 
>> We had a long thread about it months ago:
> 
> Pretty sure he was talking about whether or not mv and rm should touch
> the checkout files, not about whether their semantics should be made to
> match those of the like-named Unix commands.

I don’t see the distinction.

Fossil currently forces a two-step mv, which is different from *every other 
popular F/OSS VCS* except for CVS, and that’s only because CVS doesn’t have mv 
at all.

Fossil also forces a two-step rm.  F/OSS VCSes vary quite a bit in behavior 
here, as I cataloged here:

  http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/020032.html

That said, I think we have a well-considered exemplar to emulate:

  https://www.selenic.com/mercurial/hg.1.html#remove

As for questions about how to deal with OS semantics, I don’t think we have a 
real problem here.

File deletion semantics are straightforward on all OSes Fossil runs on.  The hg 
rm design shows how the VCS and OS can interact in a safe way.

As for file *move* semantics, the only tricky bit is how to handle moves across 
filesystems, but that’s irrelevant to Fossil since there is no way to “open” a 
Fossil repo so that it spans filesystems.

(Well, not without OS help, which would paper over the mv semantics problem, 
too.)

Bottom line: Fossil doesn’t have to blaze trail on this.  There are already 
well-trod paths.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Stephan Beal]

On Mon, Aug 3, 2015 at 9:04 PM, Ross Berteig  wrote:

> And then, there will be fresh set of edge cases with subtly different
> behavior on Windows. And for that matter, do all versions of
> Unix-descendents mv have the same quirks at the edges?
>
> IMHO, fossil does a remarkable job of handling rename now. I'm not sure
> what the ROI is for tuning the fossil mv command further...


fwiw: +1

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Graeme Pietersz]

On 04/08/15 00:34, Ross Berteig wrote:
> On 8/3/2015 11:49 AM, Andy Goth wrote:
>> On 8/3/2015 2:01 AM, Michai Ramakers wrote:
>>> On 3 August 2015 at 01:22, Matt Welland  wrote:
 I've been using (and advising others to use) addremove because
 fossil mv
 behavior did not match Unix mv. The differences were confusing.
 I've no idea
 if fossil mv now behaves exactly like mv.
>>> indeed, it does not.
>> Any plans to bring them in sync?  I often have to make a few attempts
>> until I get fossil mv to do what I want.
>
> And then, there will be fresh set of edge cases with subtly different
> behavior on Windows. And for that matter, do all versions of
> Unix-descendents mv have the same quirks at the edges?
What are the issues? I do not use mv much (because I rarely move files
and directories around) which is probably why I have not noticed
anything, but it would be nice to know
>
> IMHO, fossil does a remarkable job of handling rename now. I'm not
> sure what the ROI is for tuning the fossil mv command further...
>
>> Regarding the original question: I have never resorted to addremove when
>> intending renaming/moving files because I find the rename records to be
>> useful when tracing the ancestry of a file.
>
> Personally, I know of fossil addremove and never use it, for much the
> same reasons that Stephan mentioned. I almost never have clutter-free
> source trees, and addremove is just too all-inclusive for that work flow.
>
I use addremove all the time. I works well as long as I do wish I could
undo easily when I make mistakes with it. --dry-run help avoid them, as
does being careful with ignore-glob settings, but I still make the
occasional mistake.

-- 
Graeme Pietersz
http://moneyterms.co.uk/
http://pietersz.net/

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Jacek Cała]

The same for me. I always use mv as, I guess, add/remove destroys the
history of changes.

Re syncing with the file system, I find it ok as it is. Usually, I move
files using IDE when coding, and then find missing ones while trying to
commit. For me 'mv' works ok with the exception that when I added a renamed
file, such that 'fossil chan' gives:

MISSING myfile-oldname.txt
ADDED myfile-newname.txt

fossil complains if I try to do

$ fossil mv myfile-oldname.txt myfile-newname.txt

and then I have to do

$ fossil rm newname.txt
$ fossil mv myfile-oldname.txt myfile-newname.txt

It would be perfect for me if I could just run the mv command even if the
renamed file was already added to the current change stack.

  Cheers,
  Jacek


2015-08-03 4:53 GMT+01:00 Stephan Beal :

> Counterpoint: have never used addremove because (A) i invariably have lots
> of temp/scratch files and (B) it's a pretty alien feature (not existing
> anywhere else, AFAIK). i always use mv.
>
> - stephan
> Sent from a mobile device, possibly from bed. Please excuse brevity and
> typos.
> On Aug 3, 2015 01:22, "Matt Welland"  wrote:
>
>> I've been using (and advising others to use) addremove because fossil mv
>> behavior did not match Unix mv. The differences were confusing. I've no
>> idea if fossil mv now behaves exactly like mv. The other issue was that
>> fossil move did not keep the filesystem in sync with fossil which is also
>> confusing and error prone.
>>
>> On Sat, Aug 1, 2015 at 8:46 AM, Michai Ramakers 
>> wrote:
>>
>>> Hello,
>>>
>>> I have been avoiding 'fossil mv' a bit until recently, because I
>>> didn't trust it for no good reason. I reckon since it is in trunk, it
>>> is considered stable.
>>>
>>> In project-trees here, I move/rename dirs and files quite often. What
>>> I did earlier, was simply to move them as per filesystem, and then let
>>> 'fossil addremove' do its thing, and make a commit of only those
>>> additions/removals.
>>>
>>> I was wondering what you generally do for directory trees in motion -
>>> use add/rm or mv ? And: the benefit of fossil having a concept of
>>> 'moved file/dir' is that the user can trace ancestry crossing
>>> moves/renames more easily, is that correct? (At least that's how I use
>>> it now.)
>>>
>>> Michai
>>> ___
>>> fossil-users mailing list
>>> fossil-users@lists.fossil-scm.org
>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>
>>
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Andy Goth]

On 8/3/2015 3:37 PM, Warren Young wrote:
> On Aug 3, 2015, at 12:49 PM, Andy Goth  wrote:
>> On 8/3/2015 2:01 AM, Michai Ramakers wrote:
>>> On 3 August 2015 at 01:22, Matt Welland  wrote:
 I've no idea if fossil mv now behaves exactly like mv.
>>>
>>> indeed, it does not.
>>
>> Any plans to bring them in sync?
> 
> We had a long thread about it months ago:
> 
>   
> http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/019997.html
> 
> So far as I know, drh’s opinion remains:
> 
>   
> http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/020055.html

Pretty sure he was talking about whether or not mv and rm should touch
the checkout files, not about whether their semantics should be made to
match those of the like-named Unix commands.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Warren Young]

On Aug 3, 2015, at 12:49 PM, Andy Goth  wrote:
> 
> On 8/3/2015 2:01 AM, Michai Ramakers wrote:
>> On 3 August 2015 at 01:22, Matt Welland  wrote:
>>> I've no idea if fossil mv now behaves exactly like mv.
>> 
>> indeed, it does not.
> 
> Any plans to bring them in sync?

We had a long thread about it months ago:

  http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/019997.html

So far as I know, drh’s opinion remains:

  http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/020055.html
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Michai Ramakers]

On 1 August 2015 at 17:46, Michai Ramakers  wrote:
> Hello,
>
> I was wondering what you generally do for directory trees in motion -
> use add/rm or mv ? And: the benefit of fossil having a concept of
> 'moved file/dir' is that the user can trace ancestry crossing
> moves/renames more easily, is that correct? (At least that's how I use
> it now.)

meta-question:

if I wanted to write a small description of how exactly 'mv' behaves
w.r.t. file- and dir-argument(s), and perhaps compare to *nix 'mv',
what would be the place for this? The 'mv' command-help page, or a
separate wiki-page? I think perhaps this falls somewhere in between.

Michai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Ross Berteig]

On 8/3/2015 11:49 AM, Andy Goth wrote:

On 8/3/2015 2:01 AM, Michai Ramakers wrote:

On 3 August 2015 at 01:22, Matt Welland  wrote:

I've been using (and advising others to use) addremove because fossil mv
behavior did not match Unix mv. The differences were confusing. I've no idea
if fossil mv now behaves exactly like mv.

indeed, it does not.

Any plans to bring them in sync?  I often have to make a few attempts
until I get fossil mv to do what I want.


And then, there will be fresh set of edge cases with subtly different 
behavior on Windows. And for that matter, do all versions of 
Unix-descendents mv have the same quirks at the edges?


IMHO, fossil does a remarkable job of handling rename now. I'm not sure 
what the ROI is for tuning the fossil mv command further...



Regarding the original question: I have never resorted to addremove when
intending renaming/moving files because I find the rename records to be
useful when tracing the ancestry of a file.


Personally, I know of fossil addremove and never use it, for much the 
same reasons that Stephan mentioned. I almost never have clutter-free 
source trees, and addremove is just too all-inclusive for that work flow.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Andy Goth]

On 8/3/2015 2:01 AM, Michai Ramakers wrote:
> On 3 August 2015 at 01:22, Matt Welland  wrote:
>> I've been using (and advising others to use) addremove because fossil mv
>> behavior did not match Unix mv. The differences were confusing. I've no idea
>> if fossil mv now behaves exactly like mv.
> 
> indeed, it does not.

Any plans to bring them in sync?  I often have to make a few attempts
until I get fossil mv to do what I want.

Regarding the original question: I have never resorted to addremove when
intending renaming/moving files because I find the rename records to be
useful when tracing the ancestry of a file.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Michai Ramakers]

On 3 August 2015 at 01:22, Matt Welland  wrote:
> I've been using (and advising others to use) addremove because fossil mv
> behavior did not match Unix mv. The differences were confusing. I've no idea
> if fossil mv now behaves exactly like mv.

indeed, it does not.

Michai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Stephan Beal]

Counterpoint: have never used addremove because (A) i invariably have lots
of temp/scratch files and (B) it's a pretty alien feature (not existing
anywhere else, AFAIK). i always use mv.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity and
typos.
On Aug 3, 2015 01:22, "Matt Welland"  wrote:

> I've been using (and advising others to use) addremove because fossil mv
> behavior did not match Unix mv. The differences were confusing. I've no
> idea if fossil mv now behaves exactly like mv. The other issue was that
> fossil move did not keep the filesystem in sync with fossil which is also
> confusing and error prone.
>
> On Sat, Aug 1, 2015 at 8:46 AM, Michai Ramakers 
> wrote:
>
>> Hello,
>>
>> I have been avoiding 'fossil mv' a bit until recently, because I
>> didn't trust it for no good reason. I reckon since it is in trunk, it
>> is considered stable.
>>
>> In project-trees here, I move/rename dirs and files quite often. What
>> I did earlier, was simply to move them as per filesystem, and then let
>> 'fossil addremove' do its thing, and make a commit of only those
>> additions/removals.
>>
>> I was wondering what you generally do for directory trees in motion -
>> use add/rm or mv ? And: the benefit of fossil having a concept of
>> 'moved file/dir' is that the user can trace ancestry crossing
>> moves/renames more easily, is that correct? (At least that's how I use
>> it now.)
>>
>> Michai
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] quick poll: do you generally use add/rm or mv

[Matt Welland]

I've been using (and advising others to use) addremove because fossil mv
behavior did not match Unix mv. The differences were confusing. I've no
idea if fossil mv now behaves exactly like mv. The other issue was that
fossil move did not keep the filesystem in sync with fossil which is also
confusing and error prone.

On Sat, Aug 1, 2015 at 8:46 AM, Michai Ramakers 
wrote:

> Hello,
>
> I have been avoiding 'fossil mv' a bit until recently, because I
> didn't trust it for no good reason. I reckon since it is in trunk, it
> is considered stable.
>
> In project-trees here, I move/rename dirs and files quite often. What
> I did earlier, was simply to move them as per filesystem, and then let
> 'fossil addremove' do its thing, and make a commit of only those
> additions/removals.
>
> I was wondering what you generally do for directory trees in motion -
> use add/rm or mv ? And: the benefit of fossil having a concept of
> 'moved file/dir' is that the user can trace ancestry crossing
> moves/renames more easily, is that correct? (At least that's how I use
> it now.)
>
> Michai
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] quick poll: do you generally use add/rm or mv

[Michai Ramakers]

Hello,

I have been avoiding 'fossil mv' a bit until recently, because I
didn't trust it for no good reason. I reckon since it is in trunk, it
is considered stable.

In project-trees here, I move/rename dirs and files quite often. What
I did earlier, was simply to move them as per filesystem, and then let
'fossil addremove' do its thing, and make a commit of only those
additions/removals.

I was wondering what you generally do for directory trees in motion -
use add/rm or mv ? And: the benefit of fossil having a concept of
'moved file/dir' is that the user can trace ancestry crossing
moves/renames more easily, is that correct? (At least that's how I use
it now.)

Michai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users