Mon Aug 08 04:43:41 2005: New ticket: 485.
Transaction: Ticket created by guest
Queue: Darcs
Subject: Repository versioning
Owner: Nobody
Requestors: [EMAIL PROTECTED]
Status: new
Ticket <URL: http://bugs.darcs.net/.//Ticket/Display.html?id=485 >
I thought I'd put up a ticket for this, but I don't see it. This idea
was originally posted to darcs-user in http://abridgegame.org/pipermail/
darcs-users/2005-February/005455.html
Need: People would like to have a version number for files, or
distributions of a project, so that they can refer back to exact
versions of the project for debugging or other diagnosis.
While a hash might work, it would be hard to read over a phone. What is
desired is a simple version number like "Main 2.45" which can be spoken
easily and talked about using regular means. It would be nice to have
this for every version of a file, much like in CVS; therefor tags aren't
the solution either.
There is also a need for a shorthand notation for a patch, so that it
can be specified more easily on the command line.
Problem: In Darcs, a file is composed of a partially unordered set of
patches. Thus the versions aren't linear, where a version number is
linear. The current naming system for patches involves ling text names
and hashes.
Solution:
While a version of a file cannot have a single version number usable
accross all repo instances, it CAN have a linear number within a single
repo. Create a per-repo version number that represents the linear
progression of the contents of the file in that repo. Name the repo so
that versions of a file "in the wild" can be identified as being a
particular instance from a particular repo.
1. Create a log file in each repo recording all repo alterations, such
as record, pull, unpull, apply, tag, etc.
2. On repo init, ask for an optional (and later alterable) symbolic
name. Store this name in _darcs/prefs.
3. To calculate the version number, consult the log. Using the current
tag, scan the log to determine how many operations have been performed
under this tag. (tag unpulls make this slightly complicated. the idea
is that after an unpull, the operations are counted toward the new
current tag). The version of the repo is reported as "<reponame>
<tagname>.<operation-count>"
Example 1:
----------
Log file:
...
194 apply <patch name as seen in inventory file>
195 record ...
196 apply ...
TAG: "1.0.6"
1 apply ...
2 apply ...
3 unpull ....
4 record ....
5 amend-record ....
The version at this point, assuming the repo instance has been named
"Main" would be "Main 1.0.6.5"
Example 2:
----------
Log file:
...
TAG: "1.0.5"
194 apply ...
195 record ...
196 apply ...
TAG: "1.0.6"
1 apply ...
2 apply ...
3 unpull ....
UNTAG: "1.0.6"
197 apply ...
198 record ...
The version at this point, assuming the repo instance has been named
"Release" would be "Release 1.0.5.198"
User interface:
The proposed user interface uses the proposed query command.
$ darcs query repoversion
Release 1.0.5.198
Changing the repo symbolic name would be the same as changing the
author's name. Just edit a text file, or use any darcs mechanisms for
editing preferences.
The patches of a repo would also have unique numbers- just find the last
log entry that touches the patch in any way. This improves the
legibility of annotate and makes patch reference more concise.
Possible future extensions:
If it were possible to run a filter on a file before "letting darcs work
on it", then it would be trivial to write an extension that would scan
the file for $Revision(: [^$]*)?$ tags, replace them with "$Revision$",
let darcs do its usual work on the file, and then before writing the
file, replace any $Revision$ with $Revision: <repo version>$. This
would give the functionality of CVS, without altering any fundamental
part of darcs.
(My understanding of darcs is that is uses memory mapping, however, so
pre and post filter functions would be impossible without playing some
tricks... like maybe making an array of strings to represent the lines
of the file, and having most of them point to the memory mapping, and
others point to newly transformed strings allocated normally... I
digress)
It might also become possible to use the log to do versioning on the
repository itself... such as creating diffs that describe the difference
in patches between two repo instances, which could then be applied to
other repos. This is sort of a far-fetched idea, but would solve some
feature requests that have been mentioned in the past.
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
