=== wgrant_ is now known as wgrant [02:15] is it possible to use bzr missing on two remote branches? or does the one have to be local? === Peng__ is now known as Peng === Quintasan_ is now known as Quintasan [10:02] so, is bazaar supposed to freak out if it can't create a symlink on windows and just ...not branch a repo? [10:06] cause that seems like a very stupid reason to just abort and not be able to branch something [10:07] What handling would you propose? [10:09] windows has ntfs junctions [10:09] or just...not check out symlinks or something [10:09] cause now i can't work on this code on windows. [10:12] AuroraBorealis: yeah, it's not so good [10:13] AuroraBorealis: patches would be welcome, there's a bug about it. I think just omitting the symlinks as you say would be a big improvement over the status quo [10:13] AuroraBorealis: (so long as doing commits in the wt wouldn't accidentally delete them, etc, which is what makes it a little bit fiddly) [10:13] while i know python, i know nothing of the bazaar code base, and it bothers me that this bug is nearing 5 years old :< [10:14] but i'm not opposed to giving it a shot i guess... [10:16] AuroraBorealis: a good start might be suggesting a specific strategy on the mailing list and seeing if anyone can offer advice (or reasons why it might be a bad/difficult idea) [10:17] http://stackoverflow.com/questions/1967973/mercurial-symlinks-on-windows [10:17] It's https://bugs.launchpad.net/bzr/+bug/81689, in case you didn't know that already [10:17] Ubuntu bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows" [High,Confirmed] [10:17] according to that, it says that hg just puts them as a file with the path [10:17] which is another solution.. [10:17] Yeah, that sounds reasonable to me. [10:17] but then won't it get commited and overwrite the sym link? [10:18] Ideally perhaps we'd allow plugins to control how they are represented, but getting it working at all is more important. [10:18] i feel bazaar should just store the fact that it is a symlink or a ntfs junction, then convert it to wahtever the OS implements. [10:18] no idea if thats possible or not. [10:18] In the most naïve implementation, yes [10:19] why is that? [10:20] But I think it'd be possible to arrange for the code to do something like "if platform == 'win32' and dirstate_kind == 'symlink' and disk_kind == 'file': pretend disk kind is symlink" [10:20] yeah [10:21] Why? Because 'bzr status' etc looks at what's on disk (with os.stat, basically) and reports 'file', 'directory', 'symlink'. [10:21] subversion does this: Details: the Subversion repository has no internal concept of a symlink. It stores a "versioned symlink" as an ordinary file with an 'svn:special' property attached. The svn client (on unix) sees the property and translates the file into a symlink in the working copy. Win32 has no symlinks, so a win32 client won't do any such translation: the object appears as a normal file. [10:22] and git doesn't have to since it has to be compiled against cygwin which supports symlinks [10:23] Well, you can use bzr under cygwin too. [10:23] yes, but thats silly since its python [10:23] as far as i know, git can't be compiled natively for windows, but i might be wrong. [10:24] or at least i haven't seen it [10:25] and according to that bug report, they say that "adding os.symlink() and os.path.islink() support for windows" as been added, but only for python versions 3.2 and greater [10:26] I've used git in windows. I don't think I had cygwin. [10:28] since i keep seeing that you need admin privs to actually create a symlink (windows y u so bad??) unless you do something convulted, i feel that it should just create a file with the path inside of it for nw [10:28] so people can actually check out the repository... [10:34] AuroraBorealis: yeah, I think waiting for bzr to support python 3.2 would be an unfortunate answer [10:34] well the python bug page says versions effected: 2.7 [10:34] Although it's nice to know it's a problem that will solve itself *eventually*, but still. [10:34] i have no idea how to tell where the fixed code actually got commited [10:34] versus what version [10:35] And if it needs admin privs it's still a pretty bad workaround [10:35] well the thing is it doesn't need admin privs, its just by DEFAULT only the administrator has that priv [10:35] (and suggests that the underlying semantics might not map so well to symlinks?) [10:35] Anyway, time for a late dinner for me. [10:36] i guess i'll post to the mailing list i guess [11:15] i sent a message to the mailing list, although i don't know exactly how they work so i have no idea if i actually sent it or not o.o [11:25] It arrived. [11:26] no idea why i haven't gotten the email though o.o [11:29] thanks for sending that. it's one of several really frustrating platform specific bugs that haven't been addressed. [11:30] you are welcome. [11:31] it seems all of the version control systems have problems with this [11:31] cause the REAL problem is windows =P [13:19] hello, i just installed qbzr and bzr-explorer and was hoping to receive a GUI management tool for bzr, but unfortunately, there are no binaries in bin/sbin ... so how does this work then? [13:21] http://people.canonical.com/~jriddell/blog/qbzr.png [13:22] R33D3M33R: bzr explorer is a subcommand of bzr [13:22] R33D3M33R: running "bzr explorer" should work [13:22] brb [13:22] oh... [13:22] thanks [13:23] it works :) === Testy is now known as JasonO === JasonO is now known as Guest78948 [18:38] hello... just wonder if there is a command to show the location that will be pushed to [18:39] bzr info [18:43] if i just created a branch from trunk, will it push to the branch be default? [18:43] just trying to confirm before i mess something up :)\ [18:43] No, push is unset by default; it won't push anywhere. [18:44] You could use "bzr push :parent" to push to the parent location (and set is as the default for future pushes, if there isn't already one) [18:51] ahh ok [18:52] fullermd, thanks..much appreciated [18:52] time to go experiment on a test repo.. [19:05] * maxb crosses fingers and hopes for some successful bzr builds in the daily ppa now [19:07] argh, except bzr-svn is now a new failure because it declares a requirement on bzr << 2.5 [19:10] maxb: it's a genuine depends.. jelmer is aware. [19:31] ah [19:31] keeping the bzr daily ppa green sometimes feels a bit sisyphean [19:32] hah, there is my dictionary word of the day [19:33] ah, sisyfusarbeid.. [19:39] * maxb wonders where the gtk.gdk module has gone in oneiric [19:41] * jelmer wonders what the status of the gtk3 port is [19:46] The current bzr-builddeb failures are because URL-encoded filenames are leaking through to local fs access [19:54] I figured it was something like that, but I didn't have time to look into it yet. [19:59] hey Noldorin [20:19] There really is a huge variance in the speed at which different PPA buildds can get through the bzr testsuite [20:19] * maxb is waiting on some slow ones :-( [20:54] hmm, the next bzr-svn release is going to fix 50 of the almost 100 open bugs [20:54] I guess I should've done a release earlier... [21:13] howdy... [21:14] vila: I'm having trouble with bzrlib config's automatic quoting [21:16] he's likely not around till tomorrow, you'll probably have more luck on the mailing list [21:22] thanks === Quintasan_ is now known as Quintasan [22:05] Argh [22:05] alioth anonymous http is presenting an older version of users/jelmer/dulwich/unstable than alioth ssh [22:06] win [22:07] how much older ? [22:08] maxb: perhaps something that broken during the server migration? [22:08] likely [22:08] In fact, I dimly recall something about personal branches not being fixed [22:10] Also, they seem to have done something silly with their URLs, as http://bzr.debian.org/bzr/users/jelmer/dulwich/unstable/ is permanently redirected to http+urllib://anonscm.debian.org/bzr/bzr/users/jelmer/dulwich/unstable/ [22:10] Or just for fun, http://anonscm.debian.org/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/users/jelmer/dulwich/unstable/ gets you the same branch :-) [22:12] maxb: >< [22:14] maxb: Yeah, there was some talk about that on debian-devel@ === yofel_ is now known as yofel