| Submitter | Marcin Juszkiewicz |
|---|---|
| Date | 2009-12-02 18:19:05 |
| Message ID | <200912021919.06663.marcin@juszkiewicz.com.pl> |
| Download | mbox | patch |
| Permalink | /patch/1334/ |
| State | Rejected, archived |
| Headers | show |
Comments
On Wednesday 02 December 2009 19:19:05 Marcin Juszkiewicz wrote: > $ svn co -r 7916 > svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common@79 > 16 svn: URL > 'svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common' > doesn't exist > > But: > > $ svn co -r 7916 > svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common > > works fine. that sucks... we are doomed now. If the above directory is deleted in trunk the -r option will not work to download a old rev... z.
On Thursday 03 December 2009 06:31:57 Holger Hans Peter Freyther wrote: > that sucks... we are doomed now. If the above directory is deleted in trunk > the -r option will not work to download a old rev... Stefan just highlighted the above might sound rude. What I tried to say is that IIRC I changed the code to use @rev for the case of downloading a revision where the directory is not in trunk with the current HEAD... I don't think we can decide when to use -r and when to use @.. this is why I say we are doomed. The best thing I can think of right now is to try @ and then to go with -r... :( love z.
On Thu, 2009-12-03 at 08:01 +0100, Holger Hans Peter Freyther wrote: > On Thursday 03 December 2009 06:31:57 Holger Hans Peter Freyther wrote: > > > that sucks... we are doomed now. If the above directory is deleted in trunk > > the -r option will not work to download a old rev... > > > Stefan just highlighted the above might sound rude. What I tried to say is > that IIRC I changed the code to use @rev for the case of downloading a > revision where the directory is not in trunk with the current HEAD... > > I don't think we can decide when to use -r and when to use @.. this is why I > say we are doomed. The best thing I can think of right now is to try @ and > then to go with -r... :( I've heard reports of the same problem Marcin has from another user too. I looked into it and I really don't know what the solution is. I think you could find cases where either didn't work :(. Cheers, Richard
Marcin Juszkiewicz wrote: > $ svn co -r 7916 svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common@7916 > svn: URL 'svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common' doesn't exist > > But: > > $ svn co -r 7916 svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common > > works fine. > The R1.4 branch didn't exist in r7916 - that branch was created in r8660. The correct URL is: svn://svn.buglabs.net/bug/trunk/com.buglabs.bug.audio.common So this should work: $ svn co -r7916 svn://svn.buglabs.net/bug/trunk/com.buglabs.bug.audio.common@7916 Douglas. ======================================================================= This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. =======================================================================
Dnia środa, 16 grudnia 2009 o 02:41:43 Douglas Royds napisał(a): > Marcin Juszkiewicz wrote: > > $ svn co -r 7916 > > svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common@7 > >916 svn: URL > > 'svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common' > > doesn't exist > > > > But: > > > > $ svn co -r 7916 > > svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common > > > > works fine. > The R1.4 branch didn't exist in r7916 - 14:47 hrw@home:~$ LC_ALL=C svn info svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common Path: com.buglabs.bug.audio.common URL: svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common Repository Root: svn://svn.buglabs.net Repository UUID: 35ad6e01-222d-0410-b96a-b41bba574936 Revision: 10697 Node Kind: directory Last Changed Author: kgilmer Last Changed Rev: 7916 Last Changed Date: 2009-01-12 17:15:17 +0100 (Mon, 12 Jan 2009) And Bitbake uses "Last Changed Rev" field for AUTOREV. > that branch was created in r8660. That branch was created by using "svn move" so it has history of previous branch. And /bug/trunk/ is other branch of same code - they have common ancestor. Regards,
Patch
diff --git a/bitbake/lib/bb/fetch/svn.py b/bitbake/lib/bb/fetch/svn.py index aead162..f5dabdb 100644 --- a/bitbake/lib/bb/fetch/svn.py +++ b/bitbake/lib/bb/fetch/svn.py @@ -117,7 +117,9 @@ class Svn(Fetch): suffix = "" if ud.revision: options.append("-r %s" % ud.revision) - suffix = "@%s" % (ud.revision) + url = "%s://%s/%s/" % (proto, svnroot, ud.module) + if ud.revision != self._latest_revision(url, ud, d): + suffix = "@%s" % (ud.revision) elif ud.date: options.append("-r {%s}" % ud.date)
Hi I know that for most people here using SRCREV="${AUTOREV}" sounds bad but there are situations where it is needed. We, at BugLabs, use it for all our Java stuff which is run on our device. We got hit by svn fetcher as it uses "svn co -r REV svn://url@REV" syntax which fails on AUTOREV... Nevermind which Subversion we use (1.4.6, 1.6.6) we got same situation: $ svn co -r 7916 svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common@7916 svn: URL 'svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common' doesn't exist But: $ svn co -r 7916 svn://svn.buglabs.net/bug/branches/R1.4/qa/com.buglabs.bug.audio.common works fine. I looked at svn fetcher and prepared this change which fixes situation for me: What it does? It adds extra "svn info" run to get latest revision (think AUTOREV) and if it is not the same as wanted revision (think SRCREV) then it use "@REV" syntax. I do not feel that it is good way to solve problem so want to know what other people think about it. Regards,