Discussion:
[fossil-users] How to move/rename a file or directory?
Clemens Hintze
2008-07-31 18:50:23 UTC
Permalink
Hello,

I have a problem to find a way to re-structuring of my files without
breaking the history. Part of that re-structuring is moving files in
new subdirectories, renaming files and/or directories and that like.

But either I am too dense to find a way (what I would not dismiss at
this stage -- to hot a weather here in my town), or Fossil do not
support moving/renaming files and folders yet.

Deleting and re-adding-under-new-name would not be an option as that
breaks the history of said item!

Another question yet: *if* I remove a file from an directory it seems
that said file will not be checked out anymore, but it will still be
shown under the

http://localhost:8080/dir?name=folder1

page. Is this intended behavior or should I file a bug?

Best regards,
Clemens.
D. Richard Hipp
2008-07-31 19:34:49 UTC
Permalink
Post by Clemens Hintze
Hello,
I have a problem to find a way to re-structuring of my files without
breaking the history. Part of that re-structuring is moving files in
new subdirectories, renaming files and/or directories and that like.
But either I am too dense to find a way (what I would not dismiss at
this stage -- to hot a weather here in my town), or Fossil do not
support moving/renaming files and folders yet.
Deleting and re-adding-under-new-name would not be an option as that
breaks the history of said item!
An earlier design of fossil allow you to do this - to track history
across filename changes. This involved assigning a unique identifier
to each file. The identifier would be constant even when the filename
itself changed. The unique id was stored as an extra field in the
manifest.

I struggled with that design for over a year. There are some complex
issues related to merging and updating, and in "diff"-ing historical
versions and in displaying histories. I had most of the problems
solved, but the complications in the code and in the user interface
were considerable. So I eventually made the decision to scrap the
idea of tracking history across filename changes. History is now
associated with a filename.

I expect that you are disappointed by this news and I am sorry for
that. Nevertheless, I can say that I no regrets in making this design
change. The internal implementation, the file format, the user
interface, and my descriptions of what fossil does and how it works
are all much simpler after having removed the ability to track history
across filename changes. It was the right decision.

D. Richard Hipp
***@hwaci.com
Andreas Kupries
2008-07-31 19:50:38 UTC
Permalink
Post by D. Richard Hipp
An earlier design of fossil allow you to do this - to track history
across filename changes. This involved assigning a unique identifier
to each file. The identifier would be constant even when the filename
itself changed. The unique id was stored as an extra field in the
manifest.
I struggled with that design for over a year. There are some complex
issues related to merging and updating, and in "diff"-ing historical
versions and in displaying histories. I had most of the problems
solved, but the complications in the code and in the user interface
were considerable. So I eventually made the decision to scrap the
idea of tracking history across filename changes. History is now
associated with a filename.
I expect that you are disappointed by this news and I am sorry for
that. Nevertheless, I can say that I no regrets in making this design
change. The internal implementation, the file format, the user
interface, and my descriptions of what fossil does and how it works
are all much simpler after having removed the ability to track history
across filename changes. It was the right decision.
It might be possible to still track history somewhat across file name
changes, if we assume or enforce that a file name change is not allowed to
make changes to the contents of the file.

In that situation the two files should have the same UUID for the content
before and after the rename, allowing us to establish the link between the
two names, at least for purposes of displaying things.

No idea about the complexity this would entail. In other words, this idea is
not even half-baked when I tossed it in here.

--
Andreas Kupries <***@ActiveState.com>
Developer @ http://www.ActiveState.com
Tel: +1 778-786-1122
Clemens Hintze
2008-07-31 20:24:20 UTC
Permalink
Am 31.07.2008 um 21:50 schrieb Andreas Kupries:

(...)
Post by Andreas Kupries
Post by D. Richard Hipp
I expect that you are disappointed by this news and I am sorry for
that. Nevertheless, I can say that I no regrets in making this design
change. The internal implementation, the file format, the user
interface, and my descriptions of what fossil does and how it works
are all much simpler after having removed the ability to track history
across filename changes. It was the right decision.
This is a pity to hear. But as you already worked on it for a year or
so, I hesitate a bit to bring that back on the table ... but
nevertheless ...
Post by Andreas Kupries
It might be possible to still track history somewhat across file name
changes, if we assume or enforce that a file name change is not allowed to
make changes to the contents of the file.
This was also one idea of mine, just after Richard explained his
reasoning. At least for me, that would be a restriction I could live
with. And it would allow Fossil to recognize such movings/renamings
automatically without something like "fossil rename" or so ...

Another idea I had was, to record the renaming fact within a Control
Artifact. Then the pure information that a file was renamed could be
find out afterwards without fiddling with artificial file ids and such.

Or we could store the fact of renaming in another table for easier
access.

Or within the table filename in a new column originalName or such.

Just to mention some ideas that I had in that short time.

But I fear Richard already has thought about all those idea and
dismissed them for a reason?

(...)

Ciao,
Clemens.

Loading...