[
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
{quote}
(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 disagree?
(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 git
(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 think
(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
{quote}
> [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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
