On May 12, 2015, at 11:45 PM, Steve Stefanovich <[email protected]> wrote:
>
> What about nested checkouts? Which repo should it check to? I presume the
> first _FOSSIL_ it finds.
Yes.
I can give you a real-world case where that happens, in fact.
We have a repo that exists only to hold a set of files needed across multiple
branches of the main source repo, with independent versioning. That is, the
same set of files need to appear underneath the v8 branch, the v9 branch, and
trunk of the main source tree. A change made to one of these files needs to
appear in all branches.
We solve this problem by keeping these files in a separate repo, open it with
--nested under the trunk, then symlink it into the same place under the stable
branch checkout trees. Now a change made to one of these files from the v8
branch appears in the trunk, too, and vice versa.
Currently, if I change one of the files in that nested checkout, I have to cd
into the sub-repo’s checkout directory in order to check it in. I would prefer
to say this instead:
fossil ci subrepo/path/to/changed-file.txt
Fossil would start looking for .fslckout or _FOSSIL_ in subrepo/path/to, fail,
then proceed up the tree to subrepo/, where it would succeed. It would realize
that changed-file.txt does indeed belong to that sub-repository, so the checkin
would go ahead.
If Fossil kept going up the tree, it would find the .fslckout file of the
master repo, as it currently does, then fail because changed-file.txt is not
managed by the master repo.
> What if you make a typo that results in the path which is a valid changed
> file in unintended checkout? That would result in committing to wrong repo.
In that case, the other checkout tree probably doesn’t have any uncommitted
changes, so this error will result in a diagnostic no-op.
That’s how I work, at least. I don’t leave a tree hanging around with
uncommitted changes while I’m not actively working on it. If I have
uncommitted changes at the end of the working day, they get checked into the
trunk if not risky, checked into a branch if risky, or stashed if hopelessly
incomplete.
I acquired this habit back in the days of floppy disks when I lost about a
year’s worth of work when the single floppy I’d been using got roached.
Two is one, one is none.
> I'd rarely - if ever - commit from another directory. I always cd to
> 'correct' one, do a stat/gdiff beforehand, etc.
I can give you a case where it happens here, often.
When we find a bug in the software, make the change against the trunk version
and test it. After we’re happy with the fix, but before checking it in on the
trunk, we run a custom “backport” script which runs a diff and applies that to
the current stable branch, too.
(We created this script back when we were using svn, and thus had a choice to
either cope with all the weaknesses of svn merging and branching behavior, or
bypass it; we chose to bypass it. Maybe it would make more sense to use
merging now, but there’s little sense in replacing a working system.)
Since the backported patch is already tested, if it applies cleanly, it
probably builds cleanly, too, so there’s no need to cd over to the stable
checkout tree and re-build and re-test it. (Any regressions get caught at a
later step in our process.)
It would be convenient to be able to say this from the trunk checkout:
fossil ci ~/our-system/prev
For the curious, here’s that “backport” script:
#!/bin/bash
systemdir=“$HOME/our-system"
currdir=“$systemdir/trunk"
prevdir=“$systemdir/prev"
patchfile=~/tmp/backport.patch
cd $currdir || exit 1
fossil diff > $patchfile || exit 1
if [ -s $patchfile ]
then
cd $prevdir && patch -p1 < $patchfile && rm $patchfile
else
echo "No differences in $currdir”
fi
Just adjust the systemdir variable and adopt our “trunk” + “prev” checkout
naming scheme, and it’ll work on your Fossil trees, too.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
