[fossil-users] How to move/rename a file or directory?

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

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]

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]

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: [phone]

[Clemens Hintze]

This post might be inappropriate. Click to display it.