Nut upsdev - Jan 2012 - Mixed-commit problem solved

Well, that wasn't as nasty as I feared it would be.  Turns out that in
the general case it's possible to partition a mixed-branch revision
into branch cliques and generate multiple import-stream commits, one
for each affected branch.  

We lose only if the split commit is the source of a later directory
copy; I have a check for that that says, basically, "if you see this
fatal error, file a bug report". The NUT repo doesn't do that. I'll
be a bit surprised if I ever get such a bug report.

The results look a little kludgy. The NUT Subversion commit r87 turns
into two git commits with Fossil-ID headers 87.1 and 87.2. The commit
corresponding to 87.2 has its commit time bumped by 1 second so all
the committer/timestamp pairs will remain unique.  But it will do.

2.0-pre6 and auxiliary files have been uploaded to

http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz

for your inspection.  Remaining issues:

# 1. Have yet to find a clean merge point for any branch.
# 2. set-eol-style operations get lost; see tags windows-set-eol, reset-eol.
# 3. Should the first Eaton_SDK commit after the deleteall have a link
#    back to trunk?
# 4. Is the new_UIs-root tag still useful?  It doesn't seem to point 
#    at an actual branch.

Also, some remaining zero-fileop commits on the root branch should
probably be tagified.
>From what you said before, point 2 may actually be a non-issue.
Should I cross it off the list?
--
						>>esr>>

On Jan 6, 2012, at 7:34 PM, Eric S. Raymond wrote:
> # 1. Have yet to find a clean merge point for any branch.
I am trying to leverage reposurgeon to automate the process of finding merge
points, and I seem to be spinning my wheels. Can you provide an example of how
you are searching for merges?

e.g.

reposurgeon% merge (apcsmart-dev)
reposurgeon: :11392 cannot merge clean at target :11808
reposurgeon: target :11808 is out of date on these files: docs/man/apcsmart.txt
drivers/apcsmart.h drivers/apcsmart.c

# This doesn't seem to be the right merge point, but maybe that's
because '(apcsmart-dev)' represents the whole branch.

reposurgeon% list /merge updated apcsmart/
 11807 2011-09-12T09:54:55 merge updated apcsmart driver from apcsmart-dev
branch

reposurgeon% list (apcsmart-dev) & =H
...
 11800 2011-09-12T09:04:33 apcsmart: minor Makefile.am change

reposurgeon% list /merge updated apcsmart/
 11807 2011-09-12T09:54:55 merge updated apcsmart driver from apcsmart-dev
branch

reposurgeon% merge 11800 11807 
Seeking merge point......(1.48 sec) done.
reposurgeon: :11808 can merge clean at :12200
reposurgeon% list :12200
 12193 2011-11-23T08:46:35 Create Eaton_SDK branch

# I am not sure why this merge is so far down the trunk - it was definitely
merged before v2.6.2.

At the very least, I am a little more comfortable with the reposurgeon
interactive shell, so that should speed up my process of finding the rest of the
merge points.
> # 2. set-eol-style operations get lost; see tags windows-set-eol,
reset-eol.
Again, I think we're okay with that. But I don't have a Windows setup to
test with.
> # 3. Should the first Eaton_SDK commit after the deleteall have a link
> #    back to trunk?
Yes, and not to the deleteall (which should be tagified).
> # 4. Is the new_UIs-root tag still useful?  It doesn't seem to point 
> #    at an actual branch.
> 
> Also, some remaining zero-fileop commits on the root branch should
> probably be tagified.
I haven't had a chance to look at the last two.

I'd add this to the list: "5. with multiple fossil references in a
line, only the first gets lifted."

Especially where merges are concerned, the results will get unwieldy - one-line
descriptions are often well over 80 characters. I think it might be time to
revisit the alternate style I proposed a while back (which can probably be
handled through editing *.box) where we use a footnote-like syntax. If this were
automated (and I wouldn't mind taking a shot at it) we could also add short
Git hashes to help with quickly navigating through the tree in gitk (since they
turn into clickable links). Long-term it might be nice to patch gitk to
understand your commit ID format.

Also attached is a patch to fix the help for several commands (they did not
print anything in the interactive mode).

-- 
Charles Lepple
clepple at gmail


-------------- next part --------------
A non-text attachment was scrubbed...
Name: reposurgeon-add-help.patch
Type: application/octet-stream
Size: 2138 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120108/69184d5c/attachment.obj>

On Jan 6, 2012, at 7:34 PM, Eric S. Raymond wrote:
> # 4. Is the new_UIs-root tag still useful?  It doesn't seem to point 
> #    at an actual branch.
ESR: In terms of content, no - not useful.

Arnaud: While nothing has been committed on this branch[*], this is a good
reminder to check your development machines for any working copies with
uncommitted changes.

[*] http://trac.networkupstools.org/projects/nut/log/branches/new_UIs

-- 
Charles Lepple
clepple at gmail

On Jan 6, 2012, at 7:34 PM, Eric S. Raymond wrote:
> Also, some remaining zero-fileop commits on the root branch should
> probably be tagified.
I think we have another case of some deleteall commits masking some other
problem. From the reposurgeon Git repository, the commit "Moving
branches/Development into trunk." (2006-02-16T13:31:43Z!clepple+nut at
gmail.com) is a deleteall, but in our existing git-svn conversion and original
SVN repository, that commit is a no-op (file-wise) that connects/renames the old
branches/Development with the new trunk:

https://github.com/clepple/nut/commits/master?page=53

http://trac.networkupstools.org/projects/nut/log/trunk?limit=100&rev=431&mode=follow_copy

I'll look to see how we merged branches/Testing and trunk.

-- 
Charles Lepple
clepple at gmail