Repository rollback and new sandbox repositories
E. Wing
repository to the last check-in before the first branch was
introduced. It was starting to cause complexity which I couldn't
figure out, and I think we were misusing the branch feature like Git's
lightweight branches which Mercurial branches are not.
The rollback was basically done by killing the Assembla repo and
creating a new one. I had a snapshot of the last repo check-in before
the branches were introduced so I checked that one in. So we are back
to March 2. A tar-ball containing the last snapshot before I did the
rollback is contained in the Files section just-in-case.
I created two new repositories at Assembla to serve as the replacement
for our branch sandboxes. If we need more, feel free to create some.
Just create a new 'Space' and then go to Tools and add the Mercurial
option. Then push a clone into the new repo.
Peter, since you already made a patch, can you try applying it to the
Sandbox1 repo to reapply your experiment? And if it works, can you
tell me how I can create a diff and apply it for the second sandbox
that I did?
One more thing, I just did a Tailor/CVS resync on the mainline repo.
But I left the two sandboxes at Mar. 2. I wasn't sure if updating the
sandbox repo would cause problems for your patch or not.
The sandbox repos are at:
http://www.assembla.com/spaces/CMakeLuaSandbox1
http://www.assembla.com/spaces/CMakeLuaSandbox2
And of course, the main repo is still at:
http://www.assembla.com/spaces/CMakeLua
Anybody else who wants to be added for write permissions on the
sandbox repos, please let me know.
Thanks,
Eric
E. Wing
so I tried re-patching them to get the sandboxes up to date.
I ran:
hg diff -r 642 > my.patch
against each sandbox branch in the pre-rollback repository to get the
diff between the last March 2 update and the pre-rollback heads.
Then ran
patch -p1 < my.patch
on the new repos to apply the diff.
Then I ran hg add on remaining files (minus the Lua.patch which is
unneeded) to finish the resync.
For sandbox1, I am not sure why this diff/patch touched so many (all?)
CMake files. The sandbox2 merge only touched the files that acutally
changed.
Finally, I resynced against the Tailor/CVS repo.
I have pushed everything into the respective sandboxes so I hope
everything is up-to-date.
Peter, can you look over the sandbox1 repo to make sure everything is intact?
Thanks,
Eric
Peter Kümmel
> Okay, sorry for any pain this might cause. But I rolled back the
> repository to the last check-in before the first branch was
> introduced. It was starting to cause complexity which I couldn't
> figure out, and I think we were misusing the branch feature like Git's
> lightweight branches which Mercurial branches are not.
I still don't understand the differences. Isn't is possible to update
only one branch and to leave the others untouched? Until now a hg
branch to me looks like a real branch.
And if tailor doesn't work we shouldn't use it. We don't need all
the original commit infos in our repo. We only need the code.
>
> The rollback was basically done by killing the Assembla repo and
> creating a new one. I had a snapshot of the last repo check-in before
> the branches were introduced so I checked that one in. So we are back
> to March 2. A tar-ball containing the last snapshot before I did the
> rollback is contained in the Files section just-in-case.
>
> I created two new repositories at Assembla to serve as the replacement
> for our branch sandboxes. If we need more, feel free to create some.
> Just create a new 'Space' and then go to Tools and add the Mercurial
> option. Then push a clone into the new repo.
>
> Peter, since you already made a patch, can you try applying it to the
> Sandbox1 repo to reapply your experiment? And if it works, can you
> tell me how I can create a diff and apply it for the second sandbox
> that I did?
>
> One more thing, I just did a Tailor/CVS resync on the mainline repo.
> But I left the two sandboxes at Mar. 2. I wasn't sure if updating the
> sandbox repo would cause problems for your patch or not.
>
>
> The sandbox repos are at:
> http://www.assembla.com/spaces/CMakeLuaSandbox1
> http://www.assembla.com/spaces/CMakeLuaSandbox2
>
> And of course, the main repo is still at:
> http://www.assembla.com/spaces/CMakeLua
I think about using the git repository...
>
> Anybody else who wants to be added for write permissions on the
> sandbox repos, please let me know.
>
> Thanks,
> Eric
>
> >
--
Peter Kümmel
Peter Kümmel
> So I felt guilty about leaving the sandbox repos in the reverted state
> so I tried re-patching them to get the sandboxes up to date.
No problem, all I need is a cvs checkout, the new files, and lua.patch.
> I ran:
> hg diff -r 642 > my.patch
Yes, this should contain all changes. The difference to lua.patch is,
this file was generated by
cvs -z9 diff -uBb > lua.patch
>
> against each sandbox branch in the pre-rollback repository to get the
> diff between the last March 2 update and the pre-rollback heads.
not sure if this also extracts all you changes in sandbox2
>
>
> Then ran
> patch -p1 < my.patch
> on the new repos to apply the diff.
>
> Then I ran hg add on remaining files (minus the Lua.patch which is
> unneeded) to finish the resync.
>
> For sandbox1, I am not sure why this diff/patch touched so many (all?)
> CMake files. The sandbox2 merge only touched the files that acutally
> changed.
In sandbox1 all files where replaced with a cvs checkout and there was
a different date format 2008-03-01 <-> 2008/03/01, maybe because of my
cvs client.
>
> Finally, I resynced against the Tailor/CVS repo.
And this works now?
>
> I have pushed everything into the respective sandboxes so I hope
> everything is up-to-date.
>
> Peter, can you look over the sandbox1 repo to make sure everything is intact?
OK, but i don't like this repository hopping, couldn't we drop Tailor and do
the updates by hand and only use one repository with branches, hg or git?
When we update to cvs we first have to extract all our changes and store them
in a patch (Before the rollback a clean cvs code was in sandbox rev 652):
hg -r652 > lua.patch
or
cvs -z9 diff -uBb > lua.patch
if the CVS files are also checked in like in the git repo (this has the advantage
that we don't diff against files not managed by cvs)
Then we could update to the latest cvs code by overwriting all our changes:
cvs -z9 up -C *
And finally we reapply all our changes to the new cvs code. This is maybe simpler
than to fight with stupid merge tools.
Isn't CMakeLua now totally useless when we work on our branches?
Peter
E. Wing
>
> E. Wing wrote:
> > So I felt guilty about leaving the sandbox repos in the reverted state
> > so I tried re-patching them to get the sandboxes up to date.
>
> No problem, all I need is a cvs checkout, the new files, and lua.patch.
>
> > I ran:
> > hg diff -r 642 > my.patch
>
> Yes, this should contain all changes. The difference to lua.patch is,
> this file was generated by
> cvs -z9 diff -uBb > lua.patch
The reason I regenerated the patch from Mercurial was because when I
originally tried to use your Lua patch, it failed for me again.
>
> not sure if this also extracts all you changes in sandbox2
>
Sandbox2 is working for me. I think it did the right thing.
> > Finally, I resynced against the Tailor/CVS repo.
>
> And this works now?
Tailor always worked. Tailor only touches the intermediate repository.
There are no problems with this since it is one-way. The problems I
was having was was with the sandbox repository trying to push to the
main repo after I merged in new changes. I got multiple active heads
and Mercurial kept complaining. I couldn't figure it out and couldn't
find specific documentation on this. The Mercurial book says branching
is best left for when an entire team are power users. I do not fall
into this category. I was also having problems figuring out how to
share changes between the two sandboxes. In this, I was hoping for a
git-like lightweight branch.
> >
> > I have pushed everything into the respective sandboxes so I hope
> > everything is up-to-date.
> >
> > Peter, can you look over the sandbox1 repo to make sure everything is
> intact?
>
> OK, but i don't like this repository hopping, couldn't we drop Tailor and do
> the updates by hand and only use one repository with branches, hg or git?
> And finally we reapply all our changes to the new cvs code. This is maybe
> simpler
> than to fight with stupid merge tools.
No i disagree. You haven't had to deal with all the patch failures
I've dealt with. And the merge capabilities of the distributed SCMs
have made really complex things much simpler. I have already had to
deal with some nasty merging before you joined.
I'm sorry there are so many tools in the chain. If CMake was just
using a distributed SCM to begin with, this all goes away. If you
don't like doing the CVS updates, I will continue handling. If I fall
behind, just ping me and I'll try to do a quick update. (I'm still
planning on automating this.)
> Isn't CMakeLua now totally useless when we work on our branches?
No, this is exactly how distributed SCMs are supposed to work (Git,
Mercurial, etc). Every new development effort is put into a separate
clone/line. When a development line matures and the changes are good,
it can be merged back into other trees which want them.
So you may do stuff in your sandbox. When you like what you have but
maybe aren't ready to commit to the official, you push it to your
public sandbox. If I like your changes, I can pull your sandbox into
my sandbox and continue working. If I get something I think is good, I
can push it the same way and you can pull it. (I actually have about a
dozen private clones on my local hard disk, each focusing on a
different thing. I merge them as they become useful, and then
eventually may push something to a public repo.)
And when we decide we have changes that should be in the official
CMakeLua distribution, we push/merge our changes with the mainline
CMakeLua repository.
This is exactly how distributed SCMs are designed to work. Git has a
funny but nice feature called lightweight branching that let's you
clone within a single repository so it's like having multiple clones
without physically taking up different locations on your filesystem,
but it's the only SCM I know that has that feature. But in Git
lightweight branching, the conceptual process is still exactly the
same as having full-blown multiple clones. You still push/pull/merge
between lightweight branches as you desire.
Thanks,
Eric
Peter Kümmel
OK, you convinced me, then I use sandbox1.
But now I don't understand what Mercurial branches are good for :)
Peter
E. Wing
On the topic though, I do like the changes you been making. I think we
should consider merging your sandbox1 into the mainline soon :)
> But now I don't understand what Mercurial branches are good for :)
Same here :P
From what I've seen on the net, I think Mercurial branches may be the
#1 criticism of Mercurial. All-around, generally Mercurial gets high
marks for ease-of-use compared to Git, but branches are the exception
where Mercurial is difficult and Git really gets it right and easy. I
think there is a secondary issue of the term 'branch' being overused.
I think every SCM has a different definition of the term and it gets
confusing.
Thanks,
Eric
Peter Kümmel
> Peter, can you look over the sandbox1 repo to make sure everything is intact?
To check your synchronization with the cvs version I've replaced all the files
with the cvs version (in-place CVS folders and cvs up -C) and applied my lua.patch.
Then hg diff gives me attached diff. Does it only show changes done after your
updating or went something wrong?
Peter
E. Wing
These look like changes that were done after my last update. I noticed
the FindLua*.cmake modules have been modified. I am the maintainer for
those and I haven't made any changes. But I just resynced the Tailor
repo, and I see somebody made some changes.
So I think the merge was okay.
I just checked in the resynced repo to the mainline. I didn't touch
Sandbox1. I did do Sandbox2. I had a few merge conflicts, but I think
they only were due to new changes and the fact that I changed a bunch
of C++ code for my experiment.
You can try one last sync from the updated repo I just checked in from
your local copy of your repo:
hg pull http://hg.assembla.com/CMakeLua
Hopefully, there won't be any more differences.
Thanks,
Eric
Peter Kümmel
It still asks too much for obvious things, for instance:
<<<<<<<
/cygdrive/d/sandbox/cmakelua/CMakeLuaSandbox1/Source/cmLocalGenerator.cxx.orig.3030610000
if (!cmSystemTools::FileExists(currentStart.c_str()))
{
currentStart = this->Makefile->GetStartDirectory();
currentStart += "/CMakeLists.lua";
}
||||||| /cygdrive/c/Temp/cmLocalGenerator.cxx~base.aK3TLP
=======
if (!cmSystemTools::FileExists(currentStart.c_str()))
{
currentStart = this->Makefile->GetStartDirectory();
currentStart += "/CMakeLists.lua";
}
>>>>>>> /cygdrive/c/Temp/cmLocalGenerator.cxx~other.s9nhX7
So, what's the problem here? Line endings? Already patched?
>
> Hopefully, there won't be any more differences.
Thanks for your efforts, but I think I will update my files
directly via cvs checkouts.
Peter
E. Wing
>
> <<<<<<<
> /cygdrive/d/sandbox/cmakelua/CMakeLuaSandbox1/Source/cmLocalGenerator.cxx.orig.3030610000
> if (!cmSystemTools::FileExists(currentStart.c_str()))
> {
> currentStart = this->Makefile->GetStartDirectory();
> currentStart += "/CMakeLists.lua";
> }
> ||||||| /cygdrive/c/Temp/cmLocalGenerator.cxx~base.aK3TLP
> =======
>
> if (!cmSystemTools::FileExists(currentStart.c_str()))
> {
> currentStart = this->Makefile->GetStartDirectory();
> currentStart += "/CMakeLists.lua";
> }
>
> >>>>>>> /cygdrive/c/Temp/cmLocalGenerator.cxx~other.s9nhX7
>
> So, what's the problem here? Line endings? Already patched?
>
Sorry, I don't know. I might suspect line endings or maybe some other
whitespace differences (extra spaces at the end of line), but I just
can't tell from here. Maybe it has something to do with the fact that
all your files denoted some kind of change for me in your sandbox
(whereas the other branches did not have this problem).
> > Hopefully, there won't be any more differences.
>
> Thanks for your efforts, but I think I will update my files
> directly via cvs checkouts.
If this is going to be the norm, I encourage you to not bother with
the cvs checkouts. I will still be doing the updates via Tailor into
the mainline (and may propagate to sandboxes as needed), so you will
still be required to push/pull these changes when you interact with
the mainline branch which may contain other changes besides just a CVS
resync. If the cause of the differences is your CVS patching and it
continues, you're going to see a bunch of extra noise which will be
hard to distinguish between legitimate changes and this other thing.
Thanks,
Eric
Peter Kümmel
> so you will
> still be required to push/pull these changes when you interact with
> the mainline branch which may contain other changes besides just a CVS
> resync.
Ah, this is the problem with my approach. Then I have to find the reason
for my merge conflicts.
Peter