Re: Tagging an Alembic revision

2016-06-09 Thread Mike Bayer



On 06/09/2016 05:11 AM, Søren Løvborg wrote:

On Wed, Jun 8, 2016 at 4:32 PM, Mike Bayer > wrote:

Branch labels are exactly what solves this?What's wrong with
using a branch label?  you put "v1.2.1" as a branch label in the
target revision and then your "alembic downgrade v1.2.1" command
works exactly.


Sorry, reading the documentation I was distracted by the @head notations
etc. and missed the part where a "bare" branch label does indeed work
like a tag.

From the docs, it still seems like branch labels were designed to solve
a different problem, and just incidentally happens to solve this too,
but if you say it's a proper use of branch_labels, I'm obviously not
gonna argue. ;-)


That is all true, it was designed for the branching issue and not as 
much "tag this revision", though these concepts are always very similar 
in version control systems.





There's a weird side-effect, in that our Alembic history is (so far)
linear, so all branch labels show up for every revision, e.g.:

Branch names: v1.2.3, v1.2.2, v1.2.1, v1.2.0

That was part of what confused me, and could get unwieldy eventually,
but I guess it's just a cosmetic issue.



OK, then that is actually an argument to add a new "tags" feature as 
well that is pretty much like a branch name but doesn't get associated 
with other revisions in the history view.




Yeah, but we can't depend on people having full VCS history available,
we have to support snapshot downloads too. :-/

So branch_labels it is. Thanks!


Yeah.  But yeah, as I mentioned in my other email having a "tags" 
collection next to "branch_labels" is OK for me as well with some 
different semantics in alembic history etc. (any other effects you can 
think of?)   Basically you're alpha testing this :).






Best,
Søren

--
You received this message because you are subscribed to the Google
Groups "sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sqlalchemy-alembic+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Tagging an Alembic revision

2016-06-09 Thread Søren Løvborg
On Wed, Jun 8, 2016 at 4:32 PM, Mike Bayer  wrote:

> Branch labels are exactly what solves this?What's wrong with using a
> branch label?  you put "v1.2.1" as a branch label in the target revision
> and then your "alembic downgrade v1.2.1" command works exactly.
>

Sorry, reading the documentation I was distracted by the @head notations
etc. and missed the part where a "bare" branch label does indeed work like
a tag.

>From the docs, it still seems like branch labels were designed to solve a
different problem, and just incidentally happens to solve this too, but if
you say it's a proper use of branch_labels, I'm obviously not gonna argue.
;-)

There's a weird side-effect, in that our Alembic history is (so far)
linear, so all branch labels show up for every revision, e.g.:

Branch names: v1.2.3, v1.2.2, v1.2.1, v1.2.0

That was part of what confused me, and could get unwieldy eventually, but I
guess it's just a cosmetic issue.

of course, if you actually git tag your project, the head revision file can
> be located from that git tag.


Yeah, but we can't depend on people having full VCS history available, we
have to support snapshot downloads too. :-/

So branch_labels it is. Thanks!

Best,
Søren

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.