On Tuesday, 28 July 2009 1:44:50 Andreas Gruenbacher wrote:
ARBITRARY MERGES, LOSS OF INFORMATION =====================================
The build service backend is not capable of storing some of the information that git knows about: merges are only possible in the form of source links as described above, there is no distinction between author and committer, file modes are not stored, timestamps are computed on the server, there is no support for non-regular files or subdirectories.
Comparing version control in the build service with git, the most significant and painful difference seems to be tracking of parents: all commits in git reference all of their parent commits by sha1 checksum. The build service allows to determine the previous revisions of a package (revisions are numbered from 1 .. n), but it does not keep track of additional parents in all cases: for example, when two development branches are merged, the revisions on each of those two branches would need to be recorded as parents. (Source links do record the revision of the target package that they are based on in the "baserev" attribute, but this information is lost again when merging back into the target package.) This deficiency is causing enough problems in the build service itself: you may have noticed spurious commits in packages with a comment like "auto commit by copy to link target". With proper parent tracking, those commits would be unnecessary. Other differences include: * The build service uses md5 checksums for identifying objects (files and revisions), while git uses sha1 checksums. The git frontend works around this by keeping an on-disk cache which maps from md5 to sha1 checksums; a git backend on the server would have to do the same in order to emulate the build service API on top of a git repository. * A package revision in the build service roughly corresponds to a commit in git. Revisions in the build service are are assigned consecutive numbers starting from 1. Commits in git are identified by their sha1 checksum; it is not possible to get from a commit's sha1 checksum to the parent commit without looking at the commit itself. The git frontend keeps a mapping from revision numbers to commit sha1s; a git backend could do the same. * The build service keeps track of the package version and major release number ("vref") of each revision. The git frontend does not use this information; a git backend would have to maintain a mapping from commit sha1s to (version, vref) tuples. * (Some more relatively minor ones.) Andreas -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org