threads / patch / 8473

patch, 2 partsFix removal of series to nuke the formatversion config item.

Subject: [PATCH 2/2] Fix removal of series to nuke the formatversion config item.

## tl;dr

6 messages between Jun 6, 2007 and Jun 12, 2007. Diffs are folded; open one to read it.

replies: 5people: 2as markdown or json

Yann Dirson· Jun 6, 2007, 21:05 UTC · lore

[StGIT PATCH 0/2] Fix issues with series deletion

The following series fixes 2 problems with series deletion.

I am however not happy at all with the way we delete patches and series, starting with an existence check and then deleting. If any error occurs midway, then we are left with an inconsistent state that the user has to cleanup by hand. IMHO, we should have those methods be as robust as possible, maybe starting by removing the formatversion item, and printing a "cleaning up zombie stack" if does not find it. So at least after fixing a "delete" bug, we could rerun the same command and get to a sane state again.

Does that make sense ?

-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Yann Dirson· Jun 6, 2007, 21:05 UTC · re: Yann Dirson · lore

[PATCH 1/2] Fix removal of series with non-existant trash dir.

Otherwise it is not possible to delete a stack that never had a patch deleted (eg. a newborn stack).

Signed-off-by: Yann Dirson <ydirson@altern.org>

---

 stgit/stack.py |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

Show changes to stgit/stack.py +5 −4

diff --git a/stgit/stack.py b/stgit/stack.py
index 26b0561..30fcca7 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -679,10 +679,11 @@ class Series(StgitObject):
             for p in patches:
                 Patch(p, self.__patch_dir, self.__refs_dir).delete()
 
-            # remove the trash directory
-            for fname in os.listdir(self.__trash_dir):
-                os.remove(os.path.join(self.__trash_dir, fname))
-            os.rmdir(self.__trash_dir)
+            # remove the trash directory if any
+            if os.path.exists(self.__trash_dir):
+                for fname in os.listdir(self.__trash_dir):
+                    os.remove(os.path.join(self.__trash_dir, fname))
+                os.rmdir(self.__trash_dir)
 
             # FIXME: find a way to get rid of those manual removals
             # (move functionality to StgitObject ?)

Yann Dirson· Jun 6, 2007, 21:05 UTC · re: Yann Dirson · lore

Since this parameter is now used to decide if the branch has already been initialised, not removing it forbids to create a stack with the same name as one that was deleted.

Signed-off-by: Yann Dirson <ydirson@altern.org>

---

 stgit/stack.py |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Show changes to stgit/stack.py +1 −0

diff --git a/stgit/stack.py b/stgit/stack.py
index 30fcca7..e2bf6ac 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -718,6 +718,7 @@ class Series(StgitObject):
         config.unset('branch.%s.remote' % self.__name)
         config.unset('branch.%s.merge' % self.__name)
         config.unset('branch.%s.stgit.parentbranch' % self.__name)
+        config.unset('branch.%s.stgitformatversion' % self.__name)
 
     def refresh_patch(self, files = None, message = None, edit = False,
                       show_patch = False,

Catalin Marinas· Jun 7, 2007, 21:50 UTC · re: Yann Dirson · lore

Re: [StGIT PATCH 0/2] Fix issues with series deletion

On 06/06/07, Yann Dirson <ydirson@altern.org> wrote:

Show 8 quoted lines

> I am however not happy at all with the way we delete patches and
> series, starting with an existence check and then deleting.  If any
> error occurs midway, then we are left with an inconsistent state that
> the user has to cleanup by hand.  IMHO, we should have those methods
> be as robust as possible, maybe starting by removing the formatversion
> item, and printing a "cleaning up zombie stack" if does not find it.
> So at least after fixing a "delete" bug, we could rerun the same
> command and get to a sane state again.

This sounds OK for a quick fix. Longer term, I think we should support some kind of transactions. One idea is to put the StGIT metadata in a single file (or maybe two if we include the config) that gets checked in after every operation.

-- 
Catalin

Yann Dirson· Jun 9, 2007, 18:43 UTC · re: Catalin Marinas · lore

Re: [StGIT PATCH 0/2] Fix issues with series deletion

On Thu, Jun 07, 2007 at 10:50:00PM +0100, Catalin Marinas wrote:

Show 14 quoted lines

> On 06/06/07, Yann Dirson <ydirson@altern.org> wrote:
> >I am however not happy at all with the way we delete patches and
> >series, starting with an existence check and then deleting.  If any
> >error occurs midway, then we are left with an inconsistent state that
> >the user has to cleanup by hand.  IMHO, we should have those methods
> >be as robust as possible, maybe starting by removing the formatversion
> >item, and printing a "cleaning up zombie stack" if does not find it.
> >So at least after fixing a "delete" bug, we could rerun the same
> >command and get to a sane state again.
> 
> This sounds OK for a quick fix. Longer term, I think we should support
> some kind of transactions. One idea is to put the StGIT metadata in a
> single file (or maybe two if we include the config) that gets checked
> in after every operation.

Speaking of transactions, did you have a chance to read the proposal I posted some time ago ? As stated in another mail, I fear that approach does generalize easily to core git - but for lack of a better solution, we may want to go this way anyway...

Best regards,

-- 
Yann

Catalin Marinas· Jun 12, 2007, 22:16 UTC · re: Yann Dirson · lore

Re: [StGIT PATCH 0/2] Fix issues with series deletion

On 09/06/07, Yann Dirson <ydirson@altern.org> wrote:

> Speaking of transactions, did you have a chance to read the proposal I
> posted some time ago ?  As stated in another mail, I fear that
> approach does generalize easily to core git - but for lack of a better
> solution, we may want to go this way anyway...

Yes, I managed to read most of it at that time. I'll try to reply to the individual points in that e-mail. My idea was to store all the stack state, including patch information, in a single file rather than having them scattered around (maybe XML, sounds cool :-) but it's not easily parseable from shell-scripts).

-- 
Catalin