[02:15] <idnar> is it possible to use bzr missing on two remote branches? or does the one have to be local?
[10:02] <AuroraBorealis> so, is bazaar supposed to freak out if it can't create a symlink on windows and just ...not branch a repo?
[10:06] <AuroraBorealis> cause that seems like a very stupid reason to just abort and not be able to branch something
[10:07] <wilx> What handling would you propose?
[10:09] <AuroraBorealis> windows has ntfs junctions
[10:09] <AuroraBorealis> or just...not check out symlinks or something
[10:09] <AuroraBorealis> cause now i can't work on this code on windows.
[10:12] <spiv> AuroraBorealis: yeah, it's not so good
[10:13] <spiv> 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] <spiv> 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] <AuroraBorealis> 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] <AuroraBorealis> but i'm not opposed to giving it a shot i guess...
[10:16] <spiv> 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] <AuroraBorealis> http://stackoverflow.com/questions/1967973/mercurial-symlinks-on-windows
[10:17] <spiv> It's https://bugs.launchpad.net/bzr/+bug/81689, in case you didn't know that already
[10:17] <AuroraBorealis> according to that, it says that hg just puts them as a file with the path
[10:17] <AuroraBorealis> which is another solution..
[10:17] <spiv> Yeah, that sounds reasonable to me.
[10:17] <AuroraBorealis> but then won't it get commited and overwrite the sym link?
[10:18] <spiv> Ideally perhaps we'd allow plugins to control how they are represented, but getting it working at all is more important.
[10:18] <AuroraBorealis> 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] <AuroraBorealis> no idea if thats possible or not.
[10:18] <spiv> In the most naïve implementation, yes
[10:19] <AuroraBorealis> why is that?
[10:20] <spiv> 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] <AuroraBorealis> yeah
[10:21] <spiv> Why?  Because 'bzr status' etc looks at what's on disk (with os.stat, basically) and reports 'file', 'directory', 'symlink'.
[10:21] <AuroraBorealis> 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] <AuroraBorealis> and git doesn't have to since it has to be compiled against cygwin which supports symlinks
[10:23] <spiv> Well, you can use bzr under cygwin too.
[10:23] <AuroraBorealis> yes, but thats silly since its python
[10:23] <AuroraBorealis> as far as i know, git can't be compiled natively for windows, but i might be wrong.
[10:24] <AuroraBorealis> or at least i haven't seen it
[10:25] <AuroraBorealis> 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] <nigelb> I've used git in windows. I don't think I had cygwin.
[10:28] <AuroraBorealis> 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] <AuroraBorealis> so people can actually check out the repository...
[10:34] <spiv> AuroraBorealis: yeah, I think waiting for bzr to support python 3.2 would be an unfortunate answer
[10:34] <AuroraBorealis> well the python bug page says versions effected: 2.7
[10:34] <spiv> Although it's nice to know it's a problem that will solve itself *eventually*, but still.
[10:34] <AuroraBorealis> i have no idea how to tell where the fixed code actually got commited
[10:34] <AuroraBorealis> versus what version
[10:35] <spiv> And if it needs admin privs it's still a pretty bad workaround
[10:35] <AuroraBorealis> well the thing is it doesn't need admin privs, its just by DEFAULT only the administrator has that priv
[10:35] <spiv> (and suggests that the underlying semantics might not map so well to symlinks?)
[10:35] <spiv> Anyway, time for a late dinner for me.
[10:36] <AuroraBorealis> i guess i'll post to the mailing list i guess
[11:15] <AuroraBorealis> 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] <mgz> It arrived.
[11:26] <AuroraBorealis> no idea why i haven't gotten the email though o.o
[11:29] <mgz> thanks for sending that. it's one of several really frustrating platform specific bugs that haven't been addressed.
[11:30] <AuroraBorealis> you are welcome.
[11:31] <AuroraBorealis> it seems all of the version control systems have problems with this
[11:31] <AuroraBorealis> cause the REAL problem is windows =P
[13:19] <R33D3M33R> 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] <R33D3M33R> http://people.canonical.com/~jriddell/blog/qbzr.png
[13:22] <jelmer> R33D3M33R: bzr explorer is a subcommand of bzr
[13:22] <jelmer> R33D3M33R: running "bzr explorer" should work
[13:22] <jelmer> brb
[13:22] <R33D3M33R> oh...
[13:22] <R33D3M33R> thanks
[13:23] <R33D3M33R> it works :)
[18:38] <ls3> hello... just wonder if there is a command to show the location that will be pushed to
[18:39] <fullermd> bzr info
[18:43] <ls3> if i just created a branch from trunk, will it push to the branch be default?
[18:43] <ls3> just trying to confirm before i mess something up :)\
[18:43] <fullermd> No, push is unset by default; it won't push anywhere.
[18:44] <fullermd> 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] <ls3> ahh ok
[18:52] <ls3> fullermd, thanks..much appreciated
[18:52] <ls3> 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] <maxb> argh, except bzr-svn is now a new failure because it declares a requirement on bzr << 2.5
[19:10] <Daviey> maxb: it's a genuine depends.. jelmer is aware.
[19:31] <maxb> ah
[19:31] <maxb> keeping the bzr daily ppa green sometimes feels a bit sisyphean
[19:32] <jelmer> hah, there is my dictionary word of the day
[19:33] <jelmer> 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] <maxb> The current bzr-builddeb failures are because URL-encoded filenames are leaking through to local fs access
[19:54] <jelmer> I figured it was something like that, but I didn't have time to look into it yet.
[19:59] <jelmer> hey Noldorin
[20:19] <maxb> 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] <jelmer> hmm, the next bzr-svn release is going to fix 50 of the almost 100 open bugs
[20:54] <jelmer> I guess I should've done a release earlier...
[21:13] <dOxxx> howdy...
[21:14] <dOxxx> vila: I'm having trouble with bzrlib config's automatic quoting
[21:16] <mgz> he's likely not around till tomorrow, you'll probably have more luck on the mailing list
[21:22] <dOxxx> thanks
[22:05] <maxb> Argh
[22:05] <maxb> alioth anonymous http is presenting an older version of users/jelmer/dulwich/unstable than alioth ssh
[22:06] <lifeless> win
[22:07] <lifeless> how much older ?
[22:08] <jelmer> maxb: perhaps something that broken during the server migration?
[22:08] <maxb> likely
[22:08] <maxb> In fact, I dimly recall something about personal branches not being fixed
[22:10] <maxb> 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] <maxb> 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] <lifeless> maxb: ><
[22:14] <jelmer> maxb: Yeah, there was some talk about that on debian-devel@