Tag Info

Hot answers tagged

61

As you mentioned in your question, people fork repositories when they want to make a change the code, because you don't have write access to the original repository (unless you've been added as a collaborator by the owner of the repository). In the forked repository they have write access and can push changes. They may even contribute back to the original ...


33

Yes. You never know when more people might be brought on to the project. Also, repos allow you to rollback when you accidentally add something that doesn't work. You could use git for version control on your own machine without the need for a centralized repo. However, as long as you're using git, you might as well set up a repo on on GitHub. It only ...


27

In our line of work we tend to look for technical reasons, but in my opinion the primary reason isn't technical. If you look at GitHub Help or other GitHub tutorials, forking a repo is one of the major steps for how you "do" GitHub. When people are learning and evaluating GitHub, just about every tutorial out there is going to tell them to fork a repo as ...


18

Actually, there is little reason NOT to use a code repository. Just the fact that I can easily roll back to any prior version has covered my rear end so many times when I accidentally introduced regression bugs - despite my automated tests. If you need a recommendation - try Mercurial. It's really simple, yet very powerful. I would avoid Git because of its ...


16

You should put the unit tests in the same repository because otherwise someone has to answer to the question "Where are the tests?" every time the project is handed over from one person to another. References to other repositories tend to get invalid over time when repositories are relocated and people change from one version control system to another. Just ...


13

Git tends to experience performance problems when used with large repositories. To quote Linus: And git obviously doesn't have that kind of model at all. Git fundamnetally never really looks at less than the whole repo. Even if you limit things a bit (ie check out just a portion, or have the history go back just a bit), git ends up still ...


12

Unless there exists a specific reason for you to think that each one of them deserves an invidual repo (Will they grow a lot? Probably not!) it seems more reasonable to put them all in one repo, and save yourself the trouble of cloning all of them from 20 repos. Keeping each one in a separate repo seems like the path of creating a problem where a problem ...


12

Returning IQueryable will definitely afford more flexibility to the consumers of the Repo. it puts the responsibility of narrowing results off to the client which naturally can both be a benefit and a crutch. On the good side, you won't need to be creating tons or repository methods (at least on this layer) GetAllActiveItems, GetAllNonActiveItems, etc.. to ...


10

You should create a new repo for each independent project. Why? Someone working on project D does not have to download all the history for E and F. Git repos are cheap to initialize, so you can use as many as you like. It is painful to work with multiple projects at once when they are represented as branches in a repo: When switching from A to B to quickly ...


9

Repository returns domain objects and is built on top of mapping layers. For a very simple domain domain objects and database tables can be very much the same. If your repository is always returning exact representation of your data structure then it might actually be Table Data Gateway aka Data Access Object(DAO). Example: Your database has tables for ...


9

The entire point of Github is "social coding". Personally, I fork repositories when: I want to make a change. I think the project is interesting and may want to use it in the future, but have no easier way of saving it for later on the device I'm currently using. I want to use some or all of the code in that repository as a starting point for my own ...


9

I'm a relative newbie to version control; I've used mostly SVN, a little Mercurial, and even less Git, for only a few years now. That said, I think the following is probably good advice: Make small commits often. When you commit changes, commit only related items together to keep things coherent. This helps later on when you're looking back through commit ...


9

Short answer ... Start out with the repositories in your personal account. From there, if/when things grow and/or get popular with the community, move them to an organization account. GitHub Blog: Repository redirects are here! Long answer ... Let's look at some of your options: 1. Organization: For more information on GitHub Organization features, ...


8

As noted, svn log will get you this answer. But this really isn't suitable for time tracking -- just about all accounting systems need a hole for restatement, editing a svn commit description can be tricky if not impossible due to post-commit hooks. You might want to look at something like redmine which integrates with SVN and has a time tracking feature ...


7

Well, nowadays with the third generation of Source control, it's not that hard to start using them specially git or mercurial, I cannot think on any downside of why you should not use any of them. Also If you do not want to set a remote environment you can use sites like Github, bitbucket, CodeGoogle to keep your source up, and grab it whenever you want. I ...


7

AS the other posters pointed out, you can add more than one remote then simple push to each. There is a better way, though, of creating merged remotes to where when you push to your remote, it actually pushes to two remotes. This answer has the detailed steps: http://stackoverflow.com/a/3195446/525703


6

You are intermixing entities should not access the repositories (which is a good suggestion) and the domain layer should not access the repositories (which might be bad suggestion as long as your repositories are part of the domain layer, not the application layer). Actually, your examples show no case where an entity accesses a repository, ...


6

There really is only one legitimate answer: it depends on how the repository is to be used. At one extreme your repository is a very thin wrapper around a DBContext so you can inject a veneer of testability around a database-driven app. There really is no real world expectation that this might be used in a disconnected manner without a LINQ friendly DB ...


6

Realistically, you've got three alternatives if you want deferred execution: Do it this way - expose an IQueryable. Implement a structure that exposes specific methods for specific filters or "questions". (GetCustomersInAlaskaWithChildren, below) Implement a structure that exposes a strongly-typed filter/sort/page API and builds the IQueryable internally. ...


6

TL;DR; the equivalent of a git repository is a CVS module, not a CVS repository. CVS is designed with a notion of modules being a subdivision of a repository, and it is common to use CVS repositories with several modules having a quite independent life. As an example, it is easy to have branches specific to one module and not present in another. git has ...


5

Well, I don't know if there is such a website but you can always do that with a simple Google search: "socket" site:www.codeplex.com OR site:github.com OR site:code.google.com ...where "socket" is the term/project/code example you are looking for. It is the way multi-sites search is done.


5

Please note that I only have minor experience with the .NET framework and that this answer only relates to the architecture part of your question. As far as I understood it, you are basically applying the following architectural patterns in your application: Layers: It seems you have a persistence layer (Repository Pattern), a business logic layer and a ...


5

The whole point of the repository pattern is to allow you to abstract away the implementation behind a generic interface. You can use whatever method works best for your situation, and if you want to change it later, it shouldn't affect the rest of your application. Use whatever implementation works best (and is the easiest to understand and maintain).


5

Re: "UOW tracks the elements that needs be changed, and repository contains the logic to persist those changes, but... who call who?" You understand the basic responsibilities of these classes. You say that each of the articles, that you've read, connects them together in different ways. This implies that the decision about "who calls who" is up to you. ...


5

The main reason it is not wise to bundle your own copy of OpenSSL (or other commonly used libraries) is that your project will not be the only thing your end users install that uses those libraries. If you depend on the installed system version of OpenSSL on the host where you run, your users need only update that copy of OpenSSL when a new security issue ...


5

There is no one size fits all tool, because binary file formats are highly customized. However, some version control systems, like git, let you specify a custom merge driver for specific file formats. Here's an example. Basically, you write a program that can do the merge for any three files, and git will automatically call that program whenever needed to ...


5

They want [something that can] show their changes across all projects instead of trying to remember what project they made a change [to]. Sourcetree (a free-as-in-beer GUI Git frontend) allows you to register multiple repositories, organise them into logical groups, and then view status across all of them at once: I am not affiliated with them in any ...


4

It's called source control or revision control, and if you're working on code, having a system in place is incredibly useful and important. First off, there are online source control providers, like unfuddle and github, which provide hosting for code and a lot of other convenience around them. However, they usually cost money if you want to keep your code ...


4

Git is the answer to all of your problems--at least the ones you mentioned. There is a little bit of a learning curve to it, but it's free, and ridiculously powerful. Branching is easy (in fact, the recommended workflow is to make a branch for every single feature/bug/etc, and use throw-away branches for integration testing), off-site backup is trivial, and ...


4

Let's say we have Git repo A. Dev 1 clones Git repo A. Dev 2 clones Git repo A Dev 1 modifies files: foo, bar, and baz (from cloned Git repo A). Dev 2 modifies files: baz, bar, and foo (from cloned Git repo A). Dev 1 commits and pushes back to Git repo A. Dev 2 has to pull (fetch and merge) the latest snapshot of Git repo A before he can push to Git repo A ...



Only top voted, non community-wiki answers of a minimum length are eligible