[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    [off-list ref] |
Debian-related: [off-list ref] |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

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 <redacted>

---

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

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,

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

Signed-off-by: Yann Dirson <redacted>

---

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

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 ?)

On 06/06/07, Yann Dirson [off-list ref] 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.

-- 
Catalin

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

On 06/06/07, Yann Dirson [off-list ref] wrote:

quoted

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

On 09/06/07, Yann Dirson [off-list ref] 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