/prog/ - Bazaar considered harmful

Name: Anonymous 2010-03-15 5:16

The documentation of Bazaar^[1] states that Bazaar is slower than Git, has fewer features than Git, takes up more space than Git, is not as well documented as Git, is only used by newbies, and so on. It even says they don't believe Bazaar could be more successful than other SCM systems.

Clearly the Bazaar documentation must have been written by someone who is forced to use Bazaar but secretly loves Git.

_____
^{[1] http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html}

Name: Anonymous 2010-03-15 9:43

Protip:Bazaar was intended for a different audience to Git.

Name: Anonymous 2010-03-15 10:14

Ubertip: The intended audience of Bazaar chooses floppy backups over Bazaar.

Name: Anonymous 2010-03-15 16:32

There really is no point to this thread. No one uses Bazar anyway.^{^[1]}

^{^{___

[1] http://citation.need.ed}}

Name: Anonymous 2010-03-15 22:46

Do not listen to any documentation except THESOURCE when
git is involved, it takes at least a dozen years of zen meditation to adapt to it's UI design mentality,
clearly SVN is the better choice.
Let me demonstrate:

#Create an new repository
$> git init
Initialized empty Git repository in /.git/
$> echo anus > anus
$> git add anus
$> git commit -m'1st'
[master (root-commit) ba7f7de] 1st
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100755 anus

#New file, dont add it or anything
$> echo hax > hax

#reset --hard, the file is still there
$> git reset --hard HEAD
HEAD is now at ba7f7de 1st
$> ls
anus hax

#reset --hard, except now add it to the index before
$> git add hax
$> git reset --hard HEAD
HEAD is now at ba7f7de 1st
$> ls
anus

>>The manpage for git-reset --hard says it 'matches the working tree and index to that of the tree being switched to'
>>not 'matches the working tree and index to that of the tree being switched to, except if there are new file entries in the index in which case delete fucking everything'
FOSS USER FRIENDLY

Name: Anonymous 2010-03-15 22:52

>>5
So some aspects of git are esoteric, nobody will deny that, but at least there's not a central repository. git will always be more elegant than SVN because of this.

http://www.youtube.com/watch?v=4XpnKHJAok8

Name: Anonymous 2010-03-15 23:18

And hg is better than git.

Name: Anonymous 2010-03-16 0:22

>>7
HG HARD GAY

Name: Anonymous 2010-03-16 0:38

>>6
You need a central repository if your project contains anything but hand-typed text. How do you manage internet-based collaboration on a real GUI application, let alone a gaym, when each developer needs to download and keep a mountain of old assets just to work on the current version? Heck, even pure-text repositories become painfully large after a couple years of high activity.

In summary, NO THANK YOU!

Name: Anonymous 2010-03-16 1:18

>>9
This is actually something I've learned rather painfully. Even a 5MB SQL file gets propagated through every single revision in SVN unless you use --deltas, and even then, it's not a perfect solution because it doesn't apply to binary-mode files such as archives, executables, etc.

I imagine that git isn't too dissimilar.

>>6
What is so inherently unelegant about a central repository?

Name: Anonymous 2010-03-16 2:15

>>10
I included a link to a video wherein Linus explains the problem far better than I can.

A central repository nearly defeats the purpose of a versioning system. It turns the master branch into a sacred hub of work that is touched rarely, that interferes with everyone's working version when updated, that's difficult to branch for purpose of experiment, etc.

>>9
The difference is that while there can be a master repository that project managers can agree to be a stable branch, it's not essential to git's operation. You don't need to have one, and more significantly, you can have more than one, which makes it easier to break up a big project into modular parts and then merge them as needed.

Name: Anonymous 2010-03-16 4:28

Sup /prog/, used svn for years, recently switched to git for my indie game project and loving it. Two questions:

1) How do I store art resources? Right now I've been leaving them out of the repo completely, and just rsyncing them to my backup whenever I git push to it. Is this wise? How do large studios handle this? The last game studio I worked at just committed the baked art to svn, and never backed up the original PSDs; if you needed them, better hope the artist didn't delete them off his local box. This was of course a nightmare. I'd like to do this right... is committing the art to the repository really the right way to go?

2) How do real-world developers share code when there isn't a master repository? I'm not talking about open source projects here. I mean actual developers working on the same closed-source project in an office, say. Do they just share their repository over LAN and pull from eachother? How do they share code? This question in particular I've found *extremely* frustrating, because in days of googling, not only does no one have an answer to this question, it seems no one has even considered it a problem. Who the fuck is using git if this has never come up?

Name: Anonymous 2010-03-16 5:08

>>12
How do large studios handle this?
They use Perforce—a system designed to solve these problems rather than create them. If you try to sell them on any open-source junk, you get at most a pat on the head and an ice cream cone.

How do real-world developers share code when there isn't a master repository?
They create a master repository, then share code with it.

Name: Anonymous 2010-03-16 5:09

>>12
How do I store art resources?
% git add

when there isn't a master repository?
Amend this now. What the hell.

Name: Anonymous 2010-03-16 6:02

Art resources are for artists. They don't belong in code trees.

Name: Anonymous 2010-03-16 6:18

because in days of googling, not only does no one have an answer to this question, it seems no one has even considered it a problem
No-one has an answer, because no-one asks the question. No-one asks the question, because the answer is obvious.

>>15
mdickie quality!

Name: Anonymous 2010-03-16 8:33

>>15
* Data

Name: Anonymous 2010-03-16 11:02

>>12
Troll, but I'll bite.

Do they just share their repository over LAN and pull from eachother?

Yes, exactly! Or they set up a computer on the LAN to be a server, just like you would in SVN, and then push and pull from that, just like you "checkout" and "checkin" things with traditional SCMs, only they're pulling and pushing multiple commits to the master server at a time. It's not hard.

$ git clone ssh://192.168.1.76/product.git $ cd product $ make changes $ git commit -a -m description of changes $ git push Password: $ pause for some time $ git pull git tells you what changes have been made to which files $ more changes $ git commit -a -m another commit description $ git push Password: $ done!

Just look how simple that is!

Name: Anonymous 2010-03-16 13:24

>>13
Have you actually used Perforce? It has a nicer UI and is easier to use, but that's about it. The technical performance and reliability is a terrible joke.

Name: Anonymous 2010-03-16 14:21

>>19
I guess that ``Perforce'' needs more ``Performance''!

Name: Anonymous 2010-03-16 15:19

>>20
No no, no mans here.

Name: Anonymous 2010-03-16 16:40

>>18
You know, you could set up a hook to do the pushing for you once you commit. Then it'll feel pretty much exactly like svn.

If not for the utterly idiotic -a option, at least. Mercurial got that one right and kept commits simple. If you want more there's always extensions.

Name: Anonymous 2010-03-16 17:08

>>22
Allowing partial commits is one of git's killer features. Don't get angry at your tools for being too flexible! I don't use hooks myself because I prefer to have more control, which is exactly what git is great at: complete control of one's repos.

Name: Anonymous 2010-03-16 18:09

This: http://catb.org/esr/writings/homesteading/cathedral-bazaar/
bazaar documentation?

Name: Anonymous 2010-03-16 18:20

>>23
Complete control
Exclusively decentralized model
These two are not compatible.

Name: Anonymous 2010-03-16 18:34

>>23
Mercurial manages to do this without requiring users to type extra switches for the most common use of options. It's a pity writing an extension for git is so complex; they could really use the ability to move a lot of complexity into plugins.



$ hg help shelve

Name: Anonymous 2010-03-16 18:39

>>25
On the contrary, only in a centralized model is complete control not possible, since every change affects every user -- even branches affect users, just in a way that is hidden from them, because it adds to the size and namespace of the central repository.

Meanwhile, every git user has their own branch(es) that they have complete control over. Nothing comes in that you don't want to come in, and nothing has to go out that you don't want to go out.

Name: Anonymous 2010-03-16 18:40

Git is just a Monotone rip-off anyway.
I can't in good conscience move to a system that doesn't support partial checkouts, though, out of solidarity to my bros out there on dial-up. I've been there, and I feel their pain.

Name: Anonymous 2010-03-16 18:43

>>25
EXPERT DOUBLESPEAK

Name: Anonymous 2010-03-16 18:48

>>26
Git is low level by design. You might want to try the various front ends for Git such as Easy Git.

Name: Anonymous 2010-03-16 19:05

>>27
From the perspective of the original creator (the "repository owner"), exclusively decentralized prevents the creator from controlling the distribution. When we are talking about ability to distribute, the user's amount of control is inconsequential.

Name: Anonymous 2010-03-16 19:36

>>31
I don't understand your argument. The original creator, like any user, has a choice over what he pulls in and what he pushes out. Furthermore, a decentralized repository system is actually what enables git's scm to be fully distributed.

You appear to not really understand how git works. Perhaps you should watch the video where Linus talks about the theory and motives behind the implementation.

Name: Anonymous 2010-03-16 19:39

>>32
I understand perfectly how git works. A person that has a repository has control over the content of the git repository; not the people that originally created the content of the git repository.

Name: Anonymous 2010-03-16 20:06

>>13,14,16,18
>>12 here. I already have a master repository. It's hosted over ssh on a local server, and my developers each have a user account using git-shell. We push/pull from it like just like it's svn.

The reason I asked my question is because THE ENTIRE INTERNET keeps saying "you don't need a master repository, this isn't svn lol kthxbye". Except when I ask how I go about making this work, all four of you just now said "Duh, just make a master repository!"

Do you see the problem I am having now? See why this is frustrating? I want to get rid of this master repo because everyone keeps telling me I shouldn't have it, because git is not svn and is so much more powerful and blah blah blah. Do you see?

Name: Anonymous 2010-03-16 20:19

>>34
And just to clarify, "my developers" is currently a team of two, possibly growing slightly soon (it's just an indie game project remember.) This is why I want it decentralized. Obviously a team of thirty would greatly benefit from a master repository, but we are not ever going to be that big.

Name: Anonymous 2010-03-16 20:26

Hey could you two go explore the differences of your unsophisticated opinions in, say, /g/ or at least stop bumping this thread?

Thanks.

Name: Anonymous 2010-03-16 20:35

>>33
A person that has a repository has control over the content of the git repository; not the people that originally created the content of the git repository.

Nor do users of centralized SCMs, so I don't see the disadvantage. Those users don't even have their own repos to control, since there's only one repo! And if that repo is public, someone could come clone it and change their content however one likes.

Name: Anonymous 2010-03-17 3:16

OOooo is thisa one of those, a, fights over which, uh, filesystem is cool? XFS IS TOTALLY HIP

Name: Anonymous 2010-03-17 13:46

>>37
git repos are all public.

Name: Anonymous 2010-03-27 10:04

>>30
Git is low level by design. You might want to try the various front ends for Git such as Bazaar.

Bazaar considered harmful

1 Name: Anonymous 2010-03-15 5:16

2 Name: Anonymous 2010-03-15 9:43

3 Name: Anonymous 2010-03-15 10:14

4 Name: Anonymous 2010-03-15 16:32

5 Name: Anonymous 2010-03-15 22:46

6 Name: Anonymous 2010-03-15 22:52

7 Name: Anonymous 2010-03-15 23:18

8 Name: Anonymous 2010-03-16 0:22

9 Name: Anonymous 2010-03-16 0:38

10 Name: Anonymous 2010-03-16 1:18

11 Name: Anonymous 2010-03-16 2:15

12 Name: Anonymous 2010-03-16 4:28

13 Name: Anonymous 2010-03-16 5:08

14 Name: Anonymous 2010-03-16 5:09

15 Name: Anonymous 2010-03-16 6:02

16 Name: Anonymous 2010-03-16 6:18

17 Name: Anonymous 2010-03-16 8:33

18 Name: Anonymous 2010-03-16 11:02

19 Name: Anonymous 2010-03-16 13:24

20 Name: Anonymous 2010-03-16 14:21

21 Name: Anonymous 2010-03-16 15:19

22 Name: Anonymous 2010-03-16 16:40

23 Name: Anonymous 2010-03-16 17:08

24 Name: Anonymous 2010-03-16 18:09

25 Name: Anonymous 2010-03-16 18:20

26 Name: Anonymous 2010-03-16 18:34

27 Name: Anonymous 2010-03-16 18:39

28 Name: Anonymous 2010-03-16 18:40

29 Name: Anonymous 2010-03-16 18:43

30 Name: Anonymous 2010-03-16 18:48

31 Name: Anonymous 2010-03-16 19:05

32 Name: Anonymous 2010-03-16 19:36

33 Name: Anonymous 2010-03-16 19:39

34 Name: Anonymous 2010-03-16 20:06

35 Name: Anonymous 2010-03-16 20:19

36 Name: Anonymous 2010-03-16 20:26

37 Name: Anonymous 2010-03-16 20:35

38 Name: Anonymous 2010-03-17 3:16

39 Name: Anonymous 2010-03-17 13:46

40 Name: Anonymous 2010-03-27 10:04