qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-7738) [Qpid JMS AMQP 0-x Client] Migrate qpid-java svn to git
Date Thu, 20 Apr 2017 10:49:04 GMT

    [ https://issues.apache.org/jira/browse/QPID-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976476#comment-15976476

Robbie Gemmell commented on QPID-7738:

Some related discussion yesterday from #qpid on freenode
(10:50:19) gemmellr: lorenz: each of your two test commits went into the repo in one of the
two pushes, right?
(10:57:55) jdanek entered the room.
(11:10:51) orudyy entered the room.
(11:10:52) lorenz: yes. I also just did a single push with two commits
(11:11:01) lorenz: it seems that generated only a single mail
(11:11:26) lorenz: gemmellr: are you happy with us to proceed with the migration in this state?
(11:11:38) gemmellr: lorenz: yeah..I think thats fine, we arent bothered that there is visibility
into the push, just that it doesnt send thousands of emails
(11:11:43) lorenz: or should we seek confirmation from INFRA that this is the expected behaviour
(11:11:57) gemmellr: at worst it creates one per branch or something...not really an issue
(11:12:10) gemmellr: lorenz: I am more curious about the content of the other repo
(11:12:23) lorenz: which other repo?
(11:12:28) gemmellr: lorenz: did you retain the git-svn-id metadata deliberately?
(11:12:35) gemmellr: the client repo
(11:12:48) lorenz: let me check
(11:13:07) gemmellr: lorenz: its also a shame it onyl has the commits since the split
(11:13:35) lorenz: I did not push anything yet. what are you referring to?
(11:13:46) gemmellr: lorenz: someone did, its populated
(11:13:57) lorenz: https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git
(11:14:23) lorenz: and https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git
(11:14:23) gemmellr: lorenz: ah, i looked on github...
(11:14:51) gemmellr: lorenz: was there a github mirror for the svn repo??
(11:15:25) lorenz: yes
(11:15:38) lorenz: that has been there for quite a while
(11:15:46) lorenz: don't know who set that up
(11:17:23) lorenz: regarding your question: yes, I intend to keep the svn metadata. do you
(11:18:13) gemmellr: ah..ok, noone mentioned it. Seems a bit of a waste of infras time setting
it up given this. Will be interesting to see if it works then..the fact its still showing
the old content suggests it might not, or at least it will have a trunk branch needing deleted
(11:18:23) lorenz: and I agree it is unfortunate that we lost the pre-split histroy. but I
don't think there is anything we can do about it at this point sincs it isn't present in the
svn repo
(11:18:32) gemmellr: I wouldnt keep the svn metadata personally...the point is to move to
(11:20:58) gemmellr: lorenz: I guess its a consequence of how the split was done..looking
at it, it was an empty 'repo' creation and then moves...trimming would have made retaining
the history pretty simple
(11:21:36) gemmellr: it would still be possible now, but only with some hassle
(11:24:56) lorenz: hm... I just checked the history is in svn but not in the git repo I was
about to push. it seems svn2git somehow screwed that up
(11:25:52) gemmellr: lorenz: the history is always in svn, but git-svn will only see the current
dir structure, it doesnt do history in the same way...in part since git doenst version directories,
only files
(11:26:46) gemmellr: you could probably retain the history by effectively running a couple
migrations into the same repo, but as i say...hassle
(11:27:47) gemmellr: that there are other changes intertwined, and it wasnt just a straight
copy and trim, will make that pretty awkward to pull off, so probably best to let it go
(11:27:51) lorenz: I just talked to alex. he has a migration repo of the broker that contains
the full history and no svn metadata. we'll use that to push
(11:28:07) lorenz: we'll have to take a look at the client separately
(11:28:42) lorenz: not sure what we did differently so that I ended up without the history
and he retained it
(11:29:28) gemmellr: lorenz: which istory has he retained? back to 6.0.0, or back to the start?
(11:30:07) gemmellr: lorenz: in either case, they were split out very differently, so it wouldnt
be too surprising for them to differ
(11:30:47) lorenz: his history goes back to to 2006
(11:30:57) gemmellr: lorenz: whats now the broker repo would I presume have just been a simple
move of the entire dir...thats possibly something it can track...with the cleint, there was
a 'new repo' established inbetween the moves, which will break the chain
(11:32:03) gemmellr: lorenz: so in effect, the brokers in the same dir it always was, just
moved around...the client is in a new dir
(11:34:56) lorenz: :( alex forgot to specify the authors file so all the email addresses are
screwed up. it seems like we do not have a checkout that satisfies all criteria. we'll have
to do a new checkout. this will take a while. unlikely we will complete the migration today
(11:35:43) gemmellr: doh
(11:38:11) gemmellr: lorenz: out of interest, if it retained the full history...which tags
does it have, just 6.x ?
(11:38:34) gemmellr: for the broker
(11:39:21) lorenz: 6.x
(11:39:59) gemmellr: ok, thats what I figured, sine the other tags are in another place
(11:40:40) lorenz: yes.
(11:41:10) lorenz: I think I used the  --no-minimize-url option of svn2git and that probably
cut of the history :(
(11:41:24) gemmellr: lorenz: I dont think thats it
(11:41:40) gemmellr: lorenz: I think its the way the 'repo' was created first and then the
client moved into it
orpiske orudyy 
(11:42:20) gemmellr: lorenz: one way to find out though :)
(11:42:35) lorenz: alex and I both did a migration checkout using svn2git. his has the history
mine does not. that flag is the only difference I can think of
(11:42:52) lorenz: we both did it for the broker
(11:43:13) lorenz: I also did it for the client but currently i'm just talking about the broker
(11:43:18) gemmellr: lorenz: for the broker, yes I think that would have that effect
(11:43:38) gemmellr: lorenz: for the client, I'm not sure...
(11:46:16) lorenz: I see what you are saying
(11:47:18) lorenz: since my client checkout also had the svn metadata I have to repeat the
checkout anyway so we will see...
(11:47:54) lorenz: unfortunately, the checkout takes a long time since the apache svn repo
is so huge
(11:49:03) gemmellr: lorenz: to retain the client history, I think you would need to migrate
the java dir up to the point of the client repo creation, then futz with it to lay the client-only
history on top...and that wont be possible without changing the history to do it, since it
was a clean dir to which it got added
(11:50:10) gemmellr: lorenz: yeah...for the broekr youll need to do it all to keep the history...for
the client,y ou coudl run it from the revision before the repo area was created to speed it
up, since it wont change the outcome
(11:51:08) lorenz: that's a great idea.
(11:51:35) gemmellr: well, im guesing it wont change the result...doesnt seem like it should
if it wasnt there last time
(11:51:58) gemmellr: but, if you did use differnet options, its not impossible 
(11:53:05) gemmellr: though I do think that the new repo area probably rules out retaining
the old history without manual intervention, and a slight change in the recent history
(11:53:49) gemmellr: ultimately the history is there, just in another repo that it will be
awkward to access in due to only being in tags
(12:04:37) gemmellr: lorenz: thinking it over...it might be worth asking whether folks really
want the history...if they do, I dont think its unacceptable to change the new repo to get
it...it will end up in the same state, and the clients never been released from the existing
area so it isnt changing released history
(12:07:51) lorenz: sorry. i'm not sure I follow. are you saying we should potentially do something
to make the git repo have more history than what you currently get when you go into the svn
repo to the qpid-jms-amqp-0-x directory and type "svn log"?
(12:10:15) gemmellr: lorenz: im saying that if folks want the new git repo to have the full
commit history of how the client code got to its current state, now is a one-time opportunity
to make that happen
(12:10:54) gemmellr: lorenz: by effectively altering the first 2 commits in the client svn
area before layering the rest of the changes in, to base on top of the qpid-java tree hisotry
to the point the cleint was split out
(12:11:40) gemmellr: rather than the empty dir it was before
(12:13:29) gemmellr: lorenz: this could happen on a branch and then swap the master to retain
both accounts if folks felt need
(12:15:56) lorenz: let me try a normal svn2git and see what it comes up with. maybe it is
smarter than we give it credit for.
(12:16:39) gemmellr: lorenz: sure..I very much doubt it though
(12:16:49) lorenz: :(
(12:17:25) gemmellr: lorenz: the quick way of doing what I described woudl be to add the local
broker repo as a remote to the new client git repo, then futx with them to create the history
I described, then push that
(12:19:06) gemmellr: lorenz: the prior client history will still be in svn (and git if deisred),
and its never been released from there, so now is the only time this would be acceptable I
(12:19:30) lorenz: okay. once I have the git repos I'll come back here and discuss the state
and options
(12:21:51) gemmellr: lorenz: the no-history repo will of course be smaller, which will be
nice...so folks should basically balance up the hassle of not having history \[in the same
repo\] going forward, agaisnt the added size of the repo and having to do the work to change
the history at the split
(13:12:55) rgodfrey1: gemmellr: lorenz: about to head out to Berlin… but I think losing
all the history would be a fairly steep price to pay… history is *really* important in tracking
down issues some times
(13:13:22) rgodfrey1: I'll let you guys make the decision on the best way forward, but I'd
be for preserving history if at all possible
(13:13:49) gemmellr: rgodfrey1: I wouldnt have spent so long thinking/typing about it if I
didnt agree :)
(13:13:57) rgodfrey1: :)
(13:14:10) rgodfrey1: right - I'm going to be offline for at least the next 5 hours
(13:14:20) gemmellr: cya
(13:14:26) rgodfrey1: If any decisions are made, it would be nice to post them to the list
(13:14:34) gemmellr: agreed
(13:14:43) gemmellr: I kinda meant that by 'asking folks' :)
(13:14:48) rgodfrey1: :-)
(13:15:04) rgodfrey1: yeah - would be good to have some record of this conversation in the
user list

> [Qpid JMS AMQP 0-x Client] Migrate qpid-java svn to git 
> --------------------------------------------------------
>                 Key: QPID-7738
>                 URL: https://issues.apache.org/jira/browse/QPID-7738
>             Project: Qpid
>          Issue Type: Task
>          Components: Java Client
>            Reporter: Keith Wall
>            Assignee: Alex Rudyy
>             Fix For: qpid-java-client-0-x-6.3.0
> The Qpid Broker for Java and the 0-x Qpid JMS Client are the last two components that
use SVN.  We should migrate from to GIT.   This will simplify the site.
> Related vote thread:
> http://qpid.2158936.n2.nabble.com/RESULT-VOTE-Migrate-Qpid-Broker-J-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7662060.html
> Release discuss thread:
> http://qpid.2158936.n2.nabble.com/DISCUSS-Migrate-Qpid-Broker-for-Java-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7661505.html

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message