Re: [git-users] GIT with large projects
Not sure what you mean about designed well, but in order to switch branches without having to do a full rebuild would involve: 1. switching branches would have to auto-delete compiled modules (object files) for source files that aren't contained in the new branch in order to avoid link time collisions. Or, your build process would have to detect left over object files from a branch switch and delete them at build time. 2. from one branch to another there may be an include file (when using C/C++) that has a difference possibly necessitating a full rebuild. 3. git would have to restore files using the current date and time (as opposed to their original date/time) in order for the build system to force a recompile on those modules (I checked - git does do this!) I am sure there are many other possible system-specific issues as well, i.e. many situations where switching branches would subtly necessitate a full rebuild. They would present themselves as very hard-to-find bugs that would disappear when a full rebuild occurred. I can't imagine how any SCMS could solve problems like these. (Although, I ask the question in case there is a solution that eludes me.) Without a solution to problems like these, given a very large system, many of the cool features of a SCMS are not of much use. I bring all this up not to be difficult. I read about many cool SCMS features, but I can't see how they could be useful in a very large environment that I use all the time. I am wondering if there is a solution I am unaware of. Thinking about it, I suppose there are some design decisions that could be employed that are driven by nothing more than an attempt to resolve SCM branch issues, but there is no way I am aware of to totally fix the fundamental problems. Thanks. Blake McBride On Saturday, October 19, 2013 5:52:00 PM UTC-5, Gergely Polonkai wrote: Hello, according to your description, your project seems to be something like the Linux kernel, and Git handles that just fine. Depending on your build environment, Git branches may help you a lot, as, if it is designed well, can prevent full rebuilds. Cheers, Gergely On 19 Oct 2013 23:40, Blake McBride blak...@gmail.com javascript: wrote: Greetings, I have a large application that takes about two hours to build. Sometime I have to do partial-project commits in order to communicate development from one area to another (I can explain further but it is irrelevant to the question). I'd prefer (if I was using git rather than svn) to create a branch to commit the partial work, debug, and finally merge to the master when it is all done. This way each commit on masterwould be stable (contain no partial commits). My problem is this. Given the size of the project, I can't checkout different versions without causing a two hour build. I am sure this must be a common problem. Stated another way - when you have a very large project, branching becomes a significant problem because of build times. Are there common solutions to this sort of problem? Thanks. Blake McBride -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] GIT with large projects
Yes, of course, creating a totally new branch from where you are doesn't cause any problems because nothing changes. The problem is that, I and likely most of the world, have a handful of long-running branches - that already exist. A full rebuild is out of the question when it takes two hours. I just took a look at GO. I previously thought it was Google's replacement of GWT. No, it's a language. These days all that matters are web apps. Anything else can be written in C/C++. In terms of parallel programming, there are some really good tools for C/C++ such as silk. Take care, Blake On Sunday, October 20, 2013 3:18:32 AM UTC-5, Wes Freeman wrote: When you create a branch, if you have already compiled object files, you can keep them in your folder. You don't have to do a clean build on creation of the branch. Then you can make your changes, do incremental builds, and solve the problem/merge your code into the master. The problem lies in switching between branches that already exist, which might force a clean build... As a side note, I'm really enjoying Go's ridiculously fast build times. Wes On Sun, Oct 20, 2013 at 3:59 AM, Blake McBride blak...@gmail.comjavascript: wrote: Not sure what you mean about designed well, but in order to switch branches without having to do a full rebuild would involve: 1. switching branches would have to auto-delete compiled modules (object files) for source files that aren't contained in the new branch in order to avoid link time collisions. Or, your build process would have to detect left over object files from a branch switch and delete them at build time. 2. from one branch to another there may be an include file (when using C/C++) that has a difference possibly necessitating a full rebuild. 3. git would have to restore files using the current date and time (as opposed to their original date/time) in order for the build system to force a recompile on those modules (I checked - git does do this!) I am sure there are many other possible system-specific issues as well, i.e. many situations where switching branches would subtly necessitate a full rebuild. They would present themselves as very hard-to-find bugs that would disappear when a full rebuild occurred. I can't imagine how any SCMS could solve problems like these. (Although, I ask the question in case there is a solution that eludes me.) Without a solution to problems like these, given a very large system, many of the cool features of a SCMS are not of much use. I bring all this up not to be difficult. I read about many cool SCMS features, but I can't see how they could be useful in a very large environment that I use all the time. I am wondering if there is a solution I am unaware of. Thinking about it, I suppose there are some design decisions that could be employed that are driven by nothing more than an attempt to resolve SCM branch issues, but there is no way I am aware of to totally fix the fundamental problems. Thanks. Blake McBride On Saturday, October 19, 2013 5:52:00 PM UTC-5, Gergely Polonkai wrote: Hello, according to your description, your project seems to be something like the Linux kernel, and Git handles that just fine. Depending on your build environment, Git branches may help you a lot, as, if it is designed well, can prevent full rebuilds. Cheers, Gergely On 19 Oct 2013 23:40, Blake McBride blak...@gmail.com wrote: Greetings, I have a large application that takes about two hours to build. Sometime I have to do partial-project commits in order to communicate development from one area to another (I can explain further but it is irrelevant to the question). I'd prefer (if I was using git rather than svn) to create a branch to commit the partial work, debug, and finally merge to the master when it is all done. This way each commit on master would be stable (contain no partial commits). My problem is this. Given the size of the project, I can't checkout different versions without causing a two hour build. I am sure this must be a common problem. Stated another way - when you have a very large project, branching becomes a significant problem because of build times. Are there common solutions to this sort of problem? Thanks. Blake McBride -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com javascript:. For more options, visit
[git-users] Error 403: HTTP request failed
Hi, I create a repository called test2.git then I copy it to test2x.git when I do git clone http://gitserver/test2.git Everything goes okay. When I do git clone http://gitserver/test2x.git I get the error: error: The requested URL returned error: 403 while accessing http://gitserver/test2x.git/info/refs fatal: HTTP request failed It the same data with the same permission. Why one directory work and the other not? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] GitIgnore Not including folders again
Hi I Am trying to add an ignor exception in a gitignore file. The folder i dont want is: 02 Microsoft SQL Server/ The folder that i want included is: 02 Microsoft SQL Server/xxx/MSSQL/Backup I have tried adding into my .gitignore folder: 02 Microsoft SQL Server/**/ !02 Microsoft SQL Server/**/Backup and 02 Microsoft SQL Server/**/* !02 Microsoft SQL Server/**/Backup/**/* and 02 Microsoft SQL Server/**/* !.bak But the ignore exception (i.e. the re include is not working :-( ) Any ideas? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: GitIgnore Not including folders again
i should add i am useing msysgit 1.8.4 and the: * !.gitingnore to add empty folders does not appear to be working either. I have however tested with: *.bak !*.bak and this includes the .bak again :-/ -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] GIT with large projects
What about having your long lived branches be in separate checked out folders? On Sun, Oct 20, 2013 at 6:39 AM, Blake McBride blake1...@gmail.com wrote: Yes, of course, creating a totally new branch from where you are doesn't cause any problems because nothing changes. The problem is that, I and likely most of the world, have a handful of long-running branches - that already exist. A full rebuild is out of the question when it takes two hours. I just took a look at GO. I previously thought it was Google's replacement of GWT. No, it's a language. These days all that matters are web apps. Anything else can be written in C/C++. In terms of parallel programming, there are some really good tools for C/C++ such as silk. Take care, Blake On Sunday, October 20, 2013 3:18:32 AM UTC-5, Wes Freeman wrote: When you create a branch, if you have already compiled object files, you can keep them in your folder. You don't have to do a clean build on creation of the branch. Then you can make your changes, do incremental builds, and solve the problem/merge your code into the master. The problem lies in switching between branches that already exist, which might force a clean build... As a side note, I'm really enjoying Go's ridiculously fast build times. Wes On Sun, Oct 20, 2013 at 3:59 AM, Blake McBride blak...@gmail.com wrote: Not sure what you mean about designed well, but in order to switch branches without having to do a full rebuild would involve: 1. switching branches would have to auto-delete compiled modules (object files) for source files that aren't contained in the new branch in order to avoid link time collisions. Or, your build process would have to detect left over object files from a branch switch and delete them at build time. 2. from one branch to another there may be an include file (when using C/C++) that has a difference possibly necessitating a full rebuild. 3. git would have to restore files using the current date and time (as opposed to their original date/time) in order for the build system to force a recompile on those modules (I checked - git does do this!) I am sure there are many other possible system-specific issues as well, i.e. many situations where switching branches would subtly necessitate a full rebuild. They would present themselves as very hard-to-find bugs that would disappear when a full rebuild occurred. I can't imagine how any SCMS could solve problems like these. (Although, I ask the question in case there is a solution that eludes me.) Without a solution to problems like these, given a very large system, many of the cool features of a SCMS are not of much use. I bring all this up not to be difficult. I read about many cool SCMS features, but I can't see how they could be useful in a very large environment that I use all the time. I am wondering if there is a solution I am unaware of. Thinking about it, I suppose there are some design decisions that could be employed that are driven by nothing more than an attempt to resolve SCM branch issues, but there is no way I am aware of to totally fix the fundamental problems. Thanks. Blake McBride On Saturday, October 19, 2013 5:52:00 PM UTC-5, Gergely Polonkai wrote: Hello, according to your description, your project seems to be something like the Linux kernel, and Git handles that just fine. Depending on your build environment, Git branches may help you a lot, as, if it is designed well, can prevent full rebuilds. Cheers, Gergely On 19 Oct 2013 23:40, Blake McBride blak...@gmail.com wrote: Greetings, I have a large application that takes about two hours to build. Sometime I have to do partial-project commits in order to communicate development from one area to another (I can explain further but it is irrelevant to the question). I'd prefer (if I was using git rather than svn) to create a branch to commit the partial work, debug, and finally merge to the master when it is all done. This way each commit on master would be stable (contain no partial commits). My problem is this. Given the size of the project, I can't checkoutdifferent versions without causing a two hour build. I am sure this must be a common problem. Stated another way - when you have a very large project, branching becomes a significant problem because of build times. Are there common solutions to this sort of problem? Thanks. Blake McBride -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@**googlegroups.com**. For more options, visit https://groups.google.com/**grou**ps/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving
Re: [git-users] Error 403: HTTP request failed
On Sun, Oct 20, 2013 at 05:52:04AM -0700, shlo.af...@gmail.com wrote: Hi, I create a repository called test2.git then I copy it to test2x.git when I do git clone http://gitserver/test2.git Everything goes okay. When I do git clone http://gitserver/test2x.git I get the error: error: The requested URL returned error: 403 while accessing http://gitserver/test2x.git/info/refs fatal: HTTP request failed It the same data with the same permission. Why one directory work and the other not? I'd start with checking the webserver configuration. From wikipedia: Status code 403 responses are the result of the web server being configured to deny access, for some reason, to the requested resource by the client. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Unreadable code, Why would anyone use it? Learn a better way. -- Geoff Kuenning's contribution to the 2004 Perl Haiku Contest, Haikus about Perl - 'Dishonerable Mention' winner pgpNyGknLqN8f.pgp Description: PGP signature
Re: [git-users] GIT with large projects
Yes. That is what I do, and it works. The problems with it are: A. a lot of disk space B. can't just switch to a new branch. It had to have been or would need to be checkout out and built. Thanks! On Sunday, October 20, 2013 11:39:43 AM UTC-5, Wes Freeman wrote: What about having your long lived branches be in separate checked out folders? On Sun, Oct 20, 2013 at 6:39 AM, Blake McBride blak...@gmail.comjavascript: wrote: Yes, of course, creating a totally new branch from where you are doesn't cause any problems because nothing changes. The problem is that, I and likely most of the world, have a handful of long-running branches - that already exist. A full rebuild is out of the question when it takes two hours. I just took a look at GO. I previously thought it was Google's replacement of GWT. No, it's a language. These days all that matters are web apps. Anything else can be written in C/C++. In terms of parallel programming, there are some really good tools for C/C++ such as silk. Take care, Blake On Sunday, October 20, 2013 3:18:32 AM UTC-5, Wes Freeman wrote: When you create a branch, if you have already compiled object files, you can keep them in your folder. You don't have to do a clean build on creation of the branch. Then you can make your changes, do incremental builds, and solve the problem/merge your code into the master. The problem lies in switching between branches that already exist, which might force a clean build... As a side note, I'm really enjoying Go's ridiculously fast build times. Wes On Sun, Oct 20, 2013 at 3:59 AM, Blake McBride blak...@gmail.comwrote: Not sure what you mean about designed well, but in order to switch branches without having to do a full rebuild would involve: 1. switching branches would have to auto-delete compiled modules (object files) for source files that aren't contained in the new branch in order to avoid link time collisions. Or, your build process would have to detect left over object files from a branch switch and delete them at build time. 2. from one branch to another there may be an include file (when using C/C++) that has a difference possibly necessitating a full rebuild. 3. git would have to restore files using the current date and time (as opposed to their original date/time) in order for the build system to force a recompile on those modules (I checked - git does do this!) I am sure there are many other possible system-specific issues as well, i.e. many situations where switching branches would subtly necessitate a full rebuild. They would present themselves as very hard-to-find bugs that would disappear when a full rebuild occurred. I can't imagine how any SCMS could solve problems like these. (Although, I ask the question in case there is a solution that eludes me.) Without a solution to problems like these, given a very large system, many of the cool features of a SCMS are not of much use. I bring all this up not to be difficult. I read about many cool SCMS features, but I can't see how they could be useful in a very large environment that I use all the time. I am wondering if there is a solution I am unaware of. Thinking about it, I suppose there are some design decisions that could be employed that are driven by nothing more than an attempt to resolve SCM branch issues, but there is no way I am aware of to totally fix the fundamental problems. Thanks. Blake McBride On Saturday, October 19, 2013 5:52:00 PM UTC-5, Gergely Polonkai wrote: Hello, according to your description, your project seems to be something like the Linux kernel, and Git handles that just fine. Depending on your build environment, Git branches may help you a lot, as, if it is designed well, can prevent full rebuilds. Cheers, Gergely On 19 Oct 2013 23:40, Blake McBride blak...@gmail.com wrote: Greetings, I have a large application that takes about two hours to build. Sometime I have to do partial-project commits in order to communicate development from one area to another (I can explain further but it is irrelevant to the question). I'd prefer (if I was using git rather than svn) to create a branch to commit the partial work, debug, and finally merge to the master when it is all done. This way each commit on master would be stable (contain no partial commits). My problem is this. Given the size of the project, I can't checkoutdifferent versions without causing a two hour build. I am sure this must be a common problem. Stated another way - when you have a very large project, branching becomes a significant problem because of build times. Are there common solutions to this sort of problem? Thanks. Blake McBride -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving
Re: [git-users] GIT with large projects
On Sun, Oct 20, 2013 at 12:59:21AM -0700, Blake McBride wrote: Not sure what you mean about designed well, but in order to switch branches without having to do a full rebuild would involve: 1. switching branches would have to auto-delete compiled modules (object files) for source files that aren't contained in the new branch in order to avoid link time collisions. Or, your build process would have to detect left over object files from a branch switch and delete them at build time. Why? Isn't a switch from one branch to another basically the same as making changes in several files in between builds? Why do you need to remove the now unused object files? Surely you don't link by using wildcards so the unused object files will simply not get linked in to the final result. Of course incremental linking won't be possible but triggering a full re-link on switching branches would offer a rather cheap solution to that. 2. from one branch to another there may be an include file (when using C/C++) that has a difference possibly necessitating a full rebuild. Indeed, and again that should be handled exactly the same way as a manual change in that header file in between builds on a branch. 3. git would have to restore files using the current date and time (as opposed to their original date/time) in order for the build system to force a recompile on those modules (I checked - git does do this!) Indeed. I am sure there are many other possible system-specific issues as well, i.e. many situations where switching branches would subtly necessitate a full rebuild. They would present themselves as very hard-to-find bugs that would disappear when a full rebuild occurred. Strictly speaking any such thing would be a bug in your build system, e.g. incomplete dependency information. I can't imagine how any SCMS could solve problems like these. (Although, I ask the question in case there is a solution that eludes me.) Without a solution to problems like these, given a very large system, many of the cool features of a SCMS are not of much use. I think you imagine correctly. These problems don't fall within the purview of a VCS (git is a VCS, not an SCMS). I bring all this up not to be difficult. I read about many cool SCMS features, but I can't see how they could be useful in a very large environment that I use all the time. I am wondering if there is a solution I am unaware of. Thinking about it, I suppose there are some design decisions that could be employed that are driven by nothing more than an attempt to resolve SCM branch issues, but there is no way I am aware of to totally fix the fundamental problems. Well, many of the issues you mention can be solved by using a build system that can take advantage of a shared cache of build objects. Connect a CI system that builds each branch regularly and you can largely get around those large local re-builds. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein pgpbjf37nYUed.pgp Description: PGP signature
Re: [git-users] GIT with large projects
On Sun, 20 Oct 2013 03:39:50 -0700 (PDT) Blake McBride blake1...@gmail.com wrote: Yes, of course, creating a totally new branch from where you are doesn't cause any problems because nothing changes. The problem is that, I and likely most of the world, have a handful of long-running branches - that already exist. A full rebuild is out of the question when it takes two hours. I don't think I follow. Do you mean that you waht to develop your tentative fix on a branch forked off a side branch (meaning not 'master' and) and then integrate the ready fix into master meaning you'd need to do two checkouts and two full rebuilds to achieve the end result? If so, the answer is to use separate work trees. There are several ways to do that: 1. The most dumbed down but working just okay in terms of disk space on filesystems with sensible hardlinks (that is, not Windows) is to just clone the original repository and check out different branches in the main repository and in the clone. Unless you're using the file:// scheme explicitly when doing such a local cloning Git is smart and hardlinks everything possible in the object database of the clone to the object database of the original repository, so almost no disk space gets wasted. The downside of this approach is that if you intend to keep this check out for a long time (I mean, to develop more than one fix) you will have to sync the clone both ways (push your work to the original repo and fetch its developments to the clone). This is both doable and nothing really special but you'll have to wrap your head around this concept. 2. If you're on a POSIX system, use the git-new-workdir script [1] which sets around a new work tree with its own .git subdirectory which links everything but the truly local stuff (like the HEAD ref file) to the original repository. This allows you to not clone anything and to literally share the single Git object database while having any number of branches checked out to separate work trees. This approach does not requires pushing and fetching (as there's only one common object store) but in return it requires careful thinking before committing: never commit on a branch if this same branch is currently checked out in another work tree sharing the same object store. 3. Play with environment variables and plumbing Git commands to semi-manually work with a separate index and the work tree. This is roughly the same as (2) but does not require any filesystem-level interlinking and hence should work even on Windows. I tried to explain to someone how this is supposed to work in [4] (not really tested). I just took a look at GO. I previously thought it was Google's replacement of GWT. No, it's a language. These days all that matters are web apps. This is a very limited world view. But anyway the most visible area Go has traction in is web apps (see [3] for instance) because some people prefer to write their web apps using a language which is pleasure to work with. Anything else can be written in C/C++. Sorry for being a bit harsh but people writing C/C++ don't know *both* of these languages well enough but rather only one of them, and usually the one with ++ in its name, as those languages really are no less different than, say, C and Scheme; so it's plain ignorance. In terms of parallel programming, there are some really good tools for C/C++ such as silk. Sure, a typical case of The Blub paradox [2]. 1. https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir 2. http://c2.com/cgi/wiki?BlubParadox 3. http://talks.golang.org/2013/oscon-dl.slide 4. http://stackoverflow.com/a/18789418/720999 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] GIT with large projects
On Sun, 20 Oct 2013 19:34:32 +0200 Magnus Therning mag...@therning.org wrote: [...] Well, many of the issues you mention can be solved by using a build system that can take advantage of a shared cache of build objects. Connect a CI system that builds each branch regularly and you can largely get around those large local re-builds. Also may be the OP could look at tools like [1] and [2]. 1. https://code.google.com/p/distcc/ 2. http://ccache.samba.org/ -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] GIT with large projects
See inline comments below: On Sunday, October 20, 2013 12:34:32 PM UTC-5, Magnus Therning wrote: On Sun, Oct 20, 2013 at 12:59:21AM -0700, Blake McBride wrote: Not sure what you mean about designed well, but in order to switch branches without having to do a full rebuild would involve: 1. switching branches would have to auto-delete compiled modules (object files) for source files that aren't contained in the new branch in order to avoid link time collisions. Or, your build process would have to detect left over object files from a branch switch and delete them at build time. Why? Isn't a switch from one branch to another basically the same as making changes in several files in between builds? Ahh, no. Why do you need to remove the now unused object files? Surely you don't link by using wildcards so the unused object files will simply not get linked in to the final result. Of course incremental linking won't be possible but triggering a full re-link on switching branches would offer a rather cheap solution to that. I have 15K classes. Yes, 15 thousand. It is a Java web app, and yea, it does use wildcards. If I switched branches, the .class files are left over from before the switch. Sometimes having unnecessary .class files doesn't matter, sometimes it does! 2. from one branch to another there may be an include file (when using C/C++) that has a difference possibly necessitating a full rebuild. Indeed, and again that should be handled exactly the same way as a manual change in that header file in between builds on a branch. You are missing the point. I can't wait for a two hour build every time I switch projects. If there was a real change to a header file necessitating a full rebuild I would do it one and be done. I can't do it again and again every time I switch branches. 3. git would have to restore files using the current date and time (as opposed to their original date/time) in order for the build system to force a recompile on those modules (I checked - git does do this!) Indeed. I am sure there are many other possible system-specific issues as well, i.e. many situations where switching branches would subtly necessitate a full rebuild. They would present themselves as very hard-to-find bugs that would disappear when a full rebuild occurred. Strictly speaking any such thing would be a bug in your build system, e.g. incomplete dependency information. I think the problems I describe are non-issues in small to mid-sized projects. The problems I describe only appear in very large projects. You seem to have some idealistic view of how a very large and complex application can be cleanly structured so that the issues I describe would not occur. I can't imagine how any SCMS could solve problems like these. (Although, I ask the question in case there is a solution that eludes me.) Without a solution to problems like these, given a very large system, many of the cool features of a SCMS are not of much use. I think you imagine correctly. These problems don't fall within the purview of a VCS (git is a VCS, not an SCMS). Agreed. I suppose reading some of the hype about git, I wanted to investigate it. Git surely has a nice design. I'll likely make increasingly greater use of it - even if it doesn't provide me with scrambled eggs in the morning! I bring all this up not to be difficult. I read about many cool SCMS features, but I can't see how they could be useful in a very large environment that I use all the time. I am wondering if there is a solution I am unaware of. Thinking about it, I suppose there are some design decisions that could be employed that are driven by nothing more than an attempt to resolve SCM branch issues, but there is no way I am aware of to totally fix the fundamental problems. Well, many of the issues you mention can be solved by using a build system that can take advantage of a shared cache of build objects. Connect a CI system that builds each branch regularly and you can largely get around those large local re-builds. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org javascript: jabber: mag...@therning.orgjavascript: twitter: magthe http://therning.org/magnus As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] GIT with large projects
On Sun, Oct 20, 2013 at 11:05:30AM -0700, Blake McBride wrote: See inline comments below: On Sunday, October 20, 2013 12:34:32 PM UTC-5, Magnus Therning wrote: On Sun, Oct 20, 2013 at 12:59:21AM -0700, Blake McBride wrote: Not sure what you mean about designed well, but in order to switch branches without having to do a full rebuild would involve: 1. switching branches would have to auto-delete compiled modules (object files) for source files that aren't contained in the new branch in order to avoid link time collisions. Or, your build process would have to detect left over object files from a branch switch and delete them at build time. Why? Isn't a switch from one branch to another basically the same as making changes in several files in between builds? Ahh, no. It sure has been in every large system I've worked on. It may be different depending on programming language, I work mostly with C/C++, but others like OCaml don't behave any different. So exactly *what* is different in your setup? Why does this hit you so hard? Why do you need to remove the now unused object files? Surely you don't link by using wildcards so the unused object files will simply not get linked in to the final result. Of course incremental linking won't be possible but triggering a full re-link on switching branches would offer a rather cheap solution to that. I have 15K classes. Yes, 15 thousand. It is a Java web app, and yea, it does use wildcards. If I switched branches, the .class files are left over from before the switch. Sometimes having unnecessary .class files doesn't matter, sometimes it does! Well, to be blunt to me it sounds like you're doing something wrong if you have a single project with 15k classes. All project I've worked on have split into modules that are version controlled separately long before that happens. Then releases are controlled through a CMS that works in concert with VCS. To avoid large rebuilds we've then used caches of object files. Also, like I mentioned above you need to look at your *build system* to remove superfluous files resulting from previous builds. Your VCS is unlikely to know how your source relates to your build results. 2. from one branch to another there may be an include file (when using C/C++) that has a difference possibly necessitating a full rebuild. Indeed, and again that should be handled exactly the same way as a manual change in that header file in between builds on a branch. You are missing the point. I can't wait for a two hour build every time I switch projects. If there was a real change to a header file necessitating a full rebuild I would do it one and be done. I can't do it again and again every time I switch branches. Well, then please explain the point so I understand. To me it sounds like you would like your VCS to somehow break a dependency between two source files. If you modify something that a large portion of your sources depend on, like a config.h header file, well then Git won't be able to magically break the dependencies on that header file. What you need to do then is structure your source differently! I am sure there are many other possible system-specific issues as well, i.e. many situations where switching branches would subtly necessitate a full rebuild. They would present themselves as very hard-to-find bugs that would disappear when a full rebuild occurred. Strictly speaking any such thing would be a bug in your build system, e.g. incomplete dependency information. I think the problems I describe are non-issues in small to mid-sized projects. The problems I describe only appear in very large projects. You seem to have some idealistic view of how a very large and complex application can be cleanly structured so that the issues I describe would not occur. Oh no, unnecessary re-builds become a problem also in small projects, they just don't hurt as much. I've worked on systems that take 3-4 hours for a complete build, but through modularisation and caching of build results any build rarely took more than 15 minutes. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Don't worry about other people stealing your ideas. If your ideas are any good, you’ll have to ram them down people's throats. -- Howard Aiken, IBM Engineer pgpdsG86AAVnR.pgp Description: PGP signature
Re: [git-users] GIT with large projects
On Sunday, October 20, 2013 12:59:55 PM UTC-5, Konstantin Khomoutov wrote: On Sun, 20 Oct 2013 19:34:32 +0200 Magnus Therning mag...@therning.org javascript: wrote: [...] Well, many of the issues you mention can be solved by using a build system that can take advantage of a shared cache of build objects. Connect a CI system that builds each branch regularly and you can largely get around those large local re-builds. Also may be the OP could look at tools like [1] and [2]. My system is written in Java. Java web services use classes for the web services, and classes to represent the input and output data. Sometimes the input and/or output data can be a list - thus more classes. On top of this, the Java build process for web services auto-generates all sorts of additional, support classes for each web method. This model, not invented by me, is certainly class happy. If I change a branch that doesn't have a particular web service, I am left with all of the class files (object files for C people) plus all the generated java files (think lex and yacc for the C people) for that web service. 1. https://code.google.com/p/distcc/ 2. http://ccache.samba.org/ -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Connect gitolite user from Window GUI - Error
Hi, ( I sent this question also to gitolite group) I'm trying to run git from Windows to connect a git server on Unix. When I run from the command line: git clone git@gitserver:test2 Everything okay. But when I trying to connect to it from the Git GUI: I choose Clone Existing Repository I write in 'Source location' : git@gitserver:test2 I get the error: fatal: Couldn't find remote ref HEAD fatal: The remote end hung up unexpectedly Anyone know why? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
