Re: [fossil-users] Slight file renames

[bch]

On 11/16/15, Ron W  wrote:
> On Mon, Nov 16, 2015 at 12:38 PM, bch  wrote:
>
>> In the immediate case, it's me tracking 3rd party vendor code which I
>> depend on. I untar, add, commit. On upstream updates, I nuke the
>> 3rd-party
>> code, lay down the new release and this is where we might find renaming
>> issues as I described.
>>
> If the file names are the same other than the version, you could strip off
> the version. For example, in a script you could include:
> perl -e 'my $n = $ARGV[0]; $n =~ s/-\d+[.]\d+//; rename($ARGV[0], $n);'
> $file

This is roughly what I'm doing, but it's not 100% accurate, and for
the case of 100s of files, still tedious. I guess the point is that
there's not any special secret method available with-in or outside
fossil (outside of trying to tease-out the "root" of a filename and
pair-up ea. MISSING w/ it's EXTRA counterpart.

In this sense, the behavour of git (iiuc) would be roughly what I want
where it tracks bytes, not files (this is what I think I undertand; it
allows git to track a function being moved from one file to another --
I don't understand how it works, but it sounds like what I want --
keep track of collections of bytes regardless of the name of their
container (the filename).

> If all the such files share a common naming pattern, the following should
> be able to find and strip off the version string from the names of all such
> files (all on one line):
> find . -iregex '[a-z]+[-][0-9]+[.][0-9]+[.]txt' -type f -exec
> perl -e 'my $n = $ARGV[0]; $n =~ s/-\d+[.]\d+//; rename($ARGV[0], $n);'
> '{}' ';'
>
> You may need to modify the pattern after -iregex to match your files.
> FYI, the i in -iregex means case insensitive matching. -regex will do case
> sensitive matching.
>
> If you have trouble modifying my find command, above, to work for you, I
> can create create an equivalent Perl script that should work on MS Windows,
> Mac OSX, Linux and other Unix-like systems.
>
___
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] Slight file renames

[bch]

In the immediate case, it's me tracking 3rd party vendor code which I
depend on. I untar, add, commit. On upstream updates, I nuke the 3rd-party
code, lay down the new release and this is where we might find renaming
issues as I described.
On Nov 16, 2015 9:24 AM, "Ron W"  wrote:

>
>
> On Mon, Nov 16, 2015 at 3:02 AM, bch  wrote:
>
>> I've got some work where I've got some files whose names change between
>> commits, but are the same logical entity. For example, if I have a file:
>> libxyz-1.2.txt, which might be a description of libxyz (for version 1.2 in
>> particular), if the name changes to libxyz-1.3.txt for the next commit,
>> what I'll see on [fossil changes] is a missing libxyz-1.2.txt and an extra
>> libxyz-1.3.txt. One simple way to keep all the files tracked is to [fossil
>> rm] the 1.2 file and [fossil add] the 1.3 file, but then the logical
>> continuity of the files is lost. If one does a [fossil mv], the logical
>> continuity is preserved, but I can't think of a nice easy automated way for
>> achieving this for the case of many affected files, or (semi-)complex name
>> transforms.
>>
> How are these xyz-m.n.txt files being created? Are they generated? Is
> someone renaming the files then editing them?
>
> Our API and low level design/code documents are generated from comments in
> the source files. We don't commit these documents, though I suppose it
> would make it easier to view the evolution of the APIs and designs. If we
> were to commit them, we could any needed Fossil commands at the end of our
> generating scripts, including a "fossil mv" before the "fossil com".
>
>
> ___
> 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] Slight file renames

[Ron W]

On Mon, Nov 16, 2015 at 12:38 PM, bch  wrote:

> In the immediate case, it's me tracking 3rd party vendor code which I
> depend on. I untar, add, commit. On upstream updates, I nuke the 3rd-party
> code, lay down the new release and this is where we might find renaming
> issues as I described.
>
If the file names are the same other than the version, you could strip off
the version. For example, in a script you could include:
perl -e 'my $n = $ARGV[0]; $n =~ s/-\d+[.]\d+//; rename($ARGV[0], $n);'
$file

If all the such files share a common naming pattern, the following should
be able to find and strip off the version string from the names of all such
files (all on one line):
find . -iregex '[a-z]+[-][0-9]+[.][0-9]+[.]txt' -type f -exec
perl -e 'my $n = $ARGV[0]; $n =~ s/-\d+[.]\d+//; rename($ARGV[0], $n);'
'{}' ';'

You may need to modify the pattern after -iregex to match your files.
FYI, the i in -iregex means case insensitive matching. -regex will do case
sensitive matching.

If you have trouble modifying my find command, above, to work for you, I
can create create an equivalent Perl script that should work on MS Windows,
Mac OSX, Linux and other Unix-like systems.
___
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] Slight file renames

[Ron W]

On Mon, Nov 16, 2015 at 2:20 PM, bch  wrote:

> This is roughly what I'm doing, but it's not 100% accurate, and for
> the case of 100s of files, still tedious. I guess the point is that
> there's not any special secret method available with-in or outside
> fossil (outside of trying to tease-out the "root" of a filename and
> pair-up ea. MISSING w/ it's EXTRA counterpart.
>

Other than figuring out all the needed patterns to find and "normalize" the
names of the files, I don't know of any "special sauce" you can use.


> In this sense, the behavour of git (iiuc) would be roughly what I want
> where it tracks bytes, not files (this is what I think I undertand; it
> allows git to track a function being moved from one file to another --
> I don't understand how it works, but it sounds like what I want --
> keep track of collections of bytes regardless of the name of their
> container (the filename).
>

I didn't know git could do that.

Ignoring function renames and polymorphism, I can see using something like
ctags to virtually subdivide files into functions for tracking at that
level.
___
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] Slight file renames

[Angelo Bertolli]

On 11/16/2015 6:00 PM, bch wrote:
Further to that: 
http://stackoverflow.com/questions/4908336/can-git-really-track-the-movement-of-a-single-function-from-1-file-to-another-i 
To be clear, I don't fully understand what the git model is (I 
repeatedly hear "it doesn't track files", but I haven't had a 
"Eureka!" moment of understanding yet.


I always thought it meant git just treats your whole repository as one 
giant file (stream)

___
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] Slight file renames

[bch]

On 11/16/15, Ron W  wrote:
> On Mon, Nov 16, 2015 at 2:20 PM, bch  wrote:
>
>> This is roughly what I'm doing, but it's not 100% accurate, and for
>> the case of 100s of files, still tedious. I guess the point is that
>> there's not any special secret method available with-in or outside
>> fossil (outside of trying to tease-out the "root" of a filename and
>> pair-up ea. MISSING w/ it's EXTRA counterpart.
>>
>
> Other than figuring out all the needed patterns to find and "normalize" the
> names of the files, I don't know of any "special sauce" you can use.
>
>
>> In this sense, the behavour of git (iiuc) would be roughly what I want
>> where it tracks bytes, not files (this is what I think I undertand; it
>> allows git to track a function being moved from one file to another --
>> I don't understand how it works, but it sounds like what I want --
>> keep track of collections of bytes regardless of the name of their
>> container (the filename).
>>
>
> I didn't know git could do that.

Further to that:
http://stackoverflow.com/questions/4908336/can-git-really-track-the-movement-of-a-single-function-from-1-file-to-another-i

To be clear, I don't fully understand what the git model is (I
repeatedly hear "it doesn't track files", but I haven't had a
"Eureka!" moment of understanding yet.


> Ignoring function renames and polymorphism, I can see using something like
> ctags to virtually subdivide files into functions for tracking at that
> level.

That's an interesting thought. A ctags(-like) db would indeed be
interesting, so long  as the target-language is supported.

>
___
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] Slight file renames

[Noam Postavsky]

[apologies if shows this up twice, but I think I messed up the first time]

On Mon, Nov 16, 2015 at 2:20 PM, bch  wrote:
> In this sense, the behavour of git (iiuc) would be roughly what I want
> where it tracks bytes, not files (this is what I think I undertand; it
> allows git to track a function being moved from one file to another --
> I don't understand how it works, but it sounds like what I want --
> keep track of collections of bytes regardless of the name of their
> container (the filename).

Mercurial's addremove has a --similarity option, which could be nice
addition to fossil's addremove.

https://selenic.com/hg/help/addremove

Use the -s/--similarity option to detect renamed files. This
option takes a percentage between 0 (disabled) and 100 (files must
be identical) as its parameter. With a parameter greater than 0,
this compares every removed file with every added file and records
those similar enough as renames. Detecting renamed files this way
can be expensive. After using this option, "hg status -C" can be
used to check which files were identified as moved or renamed. If
not specified, -s/--similarity defaults to 100 and only renames of
identical files are detected.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users