Obliterate via web interface
Ashley Moran
Today we accidentally pushed a broken patch. No excuse for it, just
sloppily failed to run all automated checks, and realised we added one
file we didn't mean to, and forgot one we did. Oh well, it's
Sunday :) Locally, we can obliterate in the main repo, and push a new
version from the branch, but we'd pushed to Patch-Tag.
Any chance of a web interface to obliterate patches?
Another idea: you could make it send email announcements to all users
added to the repo. This would be a big win - it'd avoid post-
obliterate conflicts. (Although, obliterating and amend-recording a
patch that someone has pulled is probably always going to be risky.)
WDYT?
Thanks
Ashley
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
http://aviewfromafar.net/
http://twitter.com/ashleymoran
Thomas Hartman
The only thing you wouldn't have here is the repo members list, which you'd have to recreate manually.
If we allowed adding repo members from a list, which we currently don't, you could do this in one shot as well.
What do you think of that as an alternative?
Thomas Hartman
Need somewhere to host your code? patch-tag.com
Want to build a webapp? happstack.com
Ashley Moran
On 16 Mar 2009, at 00:09, Thomas Hartman wrote:
> What about just deleting the project from patch-tag, recreating with
> the same name, and push from local? (This already works.)
>
> The only thing you wouldn't have here is the repo members list,
> which you'd have to recreate manually.
>
> If we allowed adding repo members from a list, which we currently
> don't, you could do this in one shot as well.
>
> What do you think of that as an alternative?
Obliterating the enitire repository is one solution, I guess =)
Hmmm... it's a workaround, but it could be risky in a team. If
someone else had pushed another patch without you realising, you'd be
deleting their work. (Likely they'd still have a copy, but they might
not appreciate it.) Also, if in future you start maintaining other
metadata around the project, this would be lost too. I'm more
comfortable doing correction patches.
Web obliterate is not very high priority to me, but I still think it
could be useful.
Thomas Hartman
> Hmmm... it's a workaround, but it could be risky in a team.
http://darcs.net/manual/node8.html#SECTION00890000000000000000 :
"WARNING: Obliterate should not be run when there is a possibility that another user may be pulling from the same repository. Attempting to do so may cause repository corruption."
So seems to me that whenever an obliterate-worthy bad patch has made its way out of your local repo and into patch-tag, the "central" repo of your dvcs ecosystem, you are already faced with a situation where you are going to have to notify everybody in the team that there is a bad patch that they will have to obliterate locally if they have it.
I don't see much risk of inadvertently destroying other's work following my suggestion since
a) they probably have a local copy
b) you probably do too, since you presumably did a pull before hitting delete
and c) you have notified everybody you are rebasing the central repo into a version that you have done obliterate locally, and that if anybody has the bad patch they should all obliterate locally too.
You would have to do step c) even if there was an obliterate feature in patch-tag like you suggested, from my reading of the darcs manual.
> Also, if in future you start maintaining other metadata around the project, this would be lost too
Currently the only metadata that we're keeping is repo membership. How would it be if we provided a way to "revirginize" a project but keep the metadata -- which currently is just the repo membership?
So far our design philosophy has been "everything goes in the repo." So when we get wikis, todo lists, etc, this will likely all be repo-able.
However, I like giving myself a way to break the "everything goes in the repo" rule and revirginization of repos (while keeping metadata) sounds like a good way to do that, without opening the can of worms that is unsafe operationso like obliterate on the central repo.
Would this work for you?
Matthew Elder
Overall I think that the idea of obliteration doesn't fit into the use case for a shared repository. Darcs rollback is the only sane way to do this. I know your history won't be as neat, but obliterate is a tool that is really only practical for a single author to single repo relationship -- AND before they share any of these changes..
I do like Thomases idea of being able to "revirginize" the repository without losing your metadata -- but again, this is in a different vein than the original obliterate idea. We really need to add some faqs and documentation about best practices :)
Thank you for the feedback and please continue to keep us in the loop as you experience issues :)
Need somewhere to put your code? http://patch-tag.com
Want to build a webapp? http://happstack.com
Eric Kow
wrote:
> sloppily failed to run all automated checks, and realised we added one
> file we didn't mean to, and forgot one we did
It's meant for just this kind of situation, i.e. wanting to undo the
changes in a patch without getting rid of the patch.
Ashley Moran
On 16 Mar 2009, at 15:31, Matthew Elder wrote:
> As Thomas says, the Darcs documentation strongly discourages that
> you do an obliteration on a shared repository. All the work that
> goes into having to notify people to obliterate it locally is one
> pain.
Well, that was why I thought sending email notifications would be
handy ;)
> And suppose that someone doesn't get the notification to do this and
> pushes some new changes, the patch you just obliterated will show
> its ugly face again.
True, but I would imagine this only being used after a very short
time. IE it's an emergency rescue operation.
There's another valid use for this - continuous integration. Say I
set up two repositories - "project" and "project-unstable". Then I
set up a server to continuously poll the project-unstable repo, and
run all automated tests every time a new patch is detected. If that
patch is successful it could be pushed to the stable project repo,
ready for pulling. If it causes failures I'd love to be able to
obliterate it on the server and have the pushing user notified.
This CI application of obliterate would be a KILLER feature for me, as
I'm completely obsessed with automated testing*, and anything that
helps keep code deployable is a huge win for me.
> Overall I think that the idea of obliteration doesn't fit into the
> use case for a shared repository. Darcs rollback is the only sane
> way to do this. I know your history won't be as neat, but obliterate
> is a tool that is really only practical for a single author to
> single repo relationship -- AND before they share any of these
> changes..
I see your perspective on this. And in general, I agree. However, I
think there's a use for obliterate buried in there somewhere.
> I do like Thomases idea of being able to "revirginize" the
> repository without losing your metadata -- but again, this is in a
> different vein than the original obliterate idea. We really need to
> add some faqs and documentation about best practices :)
Yes, I think this could be useful too.
> Thank you for the feedback and please continue to keep us in the
> loop as you experience issues :)
Don't worry, I'm an opinionated and vociferous user, I hope you can
put up with me =)
Ashley
* it's how I earn my living...
Ashley Moran
On 17 Mar 2009, at 13:39, Eric Kow wrote:
> Have you considered the darcs rollback command?
>
> It's meant for just this kind of situation, i.e. wanting to undo the
> changes in a patch without getting rid of the patch.
I could use this - but I really want to get rid of the patch :) I
actually use darcs obliterate quite a lot locally. I think it's an
under-used command. I have a feeling that beyond the danger of
obliterating a shared patch, there could be a useable implementation
of this feature. With some record of meta-data round patch pulling/
pushing, I think it could become generally safer. Must give this some
though...
Matthew Elder
Eric Kow
> The problem is that, when you obliterate a shared patch, there is no way you
> can ensure that others will not work off of this patch. I agree with you
> that obliterate is very useful, but for cleaning up your patches before you
> share anything. I could be wrong here, but I think that was the original
> intention of the Darcs creators for this feature.
your local copy of the repository, and not a public one. The first
reason is just to go back in time. You want to see what an older
version of the repository looked like, but you don't really know by
how much and you would rather just obliterate a little bit at a time
and then check by hand. The second reason is to clean up your own
work, which is the case here.
Using obliterate on patches which are already in the wild and on the
official repository is generally not advisable. The reason is not
technical but social; darcs will be just fine, but people may be
confused if you do it. As far as darcs is concerned, it's perfectly
OK for you to do this. If somebody else works on top of the patch and
creates a dependency, then you'll just have to do without their
patches (or have them unrecord, etc). On the other hand, it's very
confusing to have patches disappear from the official repository.
I'll bet you can mitigate the confusion by telling everybody else to
obliterate the same patch (for example, by editing your _darcs/prefs/
motd file) or take a chance that most people haven't pulled the patch
yet, and that you don't mind if only a small handful of people are so
confused. So avoiding the use of obliterate on public patches is
really just a "best practice" more than anything else.
(Of course, it may well be the case that you really do thing most
people haven't grabbed the patch yet, or that your project can live
with the small amount of confusion, which I might understand. And
it's definitely not the end of the world if you do use obliterate.
Darcs will be fine)
Ashley Moran
On 18 Mar 2009, at 14:21, Eric Kow wrote:
> Using obliterate on patches which are already in the wild and on the
> official repository is generally not advisable. The reason is not
> technical but social; darcs will be just fine, but people may be
> confused if you do it.
> <snip>
> I'll bet you can mitigate the confusion by telling everybody else to
> obliterate the same patch (for example, by editing your _darcs/prefs/
> motd file) or take a chance that most people haven't pulled the patch
> yet, and that you don't mind if only a small handful of people are so
> confused. So avoiding the use of obliterate on public patches is
> really just a "best practice" more than anything else.
Hey Eric - you've hit the nail on the head =) And also answered
Matthew and Thomas's concerns. This is exactly what I was thinking
but failed to express - the problem is not obliterate, but the
communication needs around it. But with Patch-Tag, we have something
that could potentially solve this issue, right?
I mean - could Patch-Tag know that a patch was obliterated, and inform
owners of forked repos that a patch has been recalled? I think this
could be a really powerful GitHub-beating social feature: rather than
release a correction patch, release a "recall", implemented with darcs
obliterate.
Not saying that this would be easy - it may require changes to darcs?
(To track obliterated patches perhaps, just brainstorming.) And not
saying it's high priority either. But I think having a hosted darcs
solution might change some of the social mechanics around patch-based
SCM.
WDYAT?
Ashley