4 ms·

I hope one day all of this will be as easy as in SVN. eg.: I have repository https://example.com/myrepo https://example.com/myrepo And i can simply do: svn c

by harvie 5y ago

I hope one day all of this will be as easy as in SVN. eg.: I have repository https://example.com/myrepo https://example.com/myrepo And i can simply do: svn co https://example.com/myrepo/some/directory/ https://example.com/myrepo/some/directory/ And i can work with that subdirectory as if it was actual repo. Completely transparently. This i really miss in git.

Gigachad 5y ago
I'm working in hell right now. The current company has the site frontend, backend, and tests in separate repos and it's basically impossible to do anything without force merging because the build is broken without a chicken and egg situation between the 3 pull requests.
- laurent123456 5y ago
  I worked at a company that not only did that, but also decided to split the main web app into multiple repos, one per country. It was so much fun to do anything in this project.
  - xorcist 5y ago
    Now, that's a microservice if there ever was one!
  - Iwan-Zotow 5y ago
    that is some good office porno!
- hinkley 5y ago
  You might want the front end and backend to be compatible across revision numbers, so that’s less of a problem and more of an impedance mismatch with your process. The tests are a trickier problem, in theory you could lock version numbers (the new behavior increments to the new tests) but tests have bugs, and this doesn’t solve two people making behavioral changes at the same time. Short of merging the tests into the respective projects, going full feature toggle for all breaking changes is the only other lever that comes to mind.
  - erik_seaberg 5y ago
    This. Deployments and rollbacks are not atomic, so atomic commits do not make frontend+backend breaking changes safe.
  - Gigachad 5y ago
    My thinking is that the tests _have_ to be merged with frontend since they do stuff like "Find the button with the content 'continue' and then click it" There is no such thing as backwards compatible changes to button content but yeah you are right, it would be possible to create backwards compatible API changes but I don't know if it's even worth it since we are the only users of the api, and it is only used for the frontend.
    - nitrogen 5y ago
      There is no such thing as backwards compatible changes to button content If your form html is reasonably semantically structured, and/or you give meaningful IDs to each interactive element, then your tests can be made somewhat robust against content changes. E.g. "click button #next-step" rather than "click the word Next". If your frontend is a desktop or mobile app, look for ways to introspect the widget hierarchy to do the same thing (I know this is possible in e.g. Swing).
      - Vinnl 5y ago
        But generally you'll want to emulate how users use your application, which is looking for a button with a particular label (bonus points if your tests are looking for the accessible label), rather than something with a given ID.
williamvds 5y ago
With shallow checkouts cloning is much quicker. You could try combining it with sparse checkouts too. You can even have Git fetch the full history in the background, and from a quick test you can do stuff like commit while it's fetching. Obviously the limited history means commands like log and blame will be inaccurate until it's done. $ git clone --depth=1 <url> $ cd repo $ git fetch --unshallow & $ <do work>
- vtbassmatt 5y ago
  This is really expensive for the server (the unshallow step specifically). Consider a partial clone here instead.
  - williamvds 5y ago
    Is unshallowing any more expensive than a normal clone? The shallow clone is for the benefit of the user so they can get to work sooner.
    - vtbassmatt 5y ago
      It is, because of the way the server has to recompute packfiles. I realize that you may choose to optimize for the user over the server, but a partial (blobless) clone should satisfy both.
      - erik_seaberg 5y ago
        Does the server rule out sending a packfile that you only need 95% of? That seems like a good thing to optimize.
zwieback 5y ago
Yeah, that's really the one thing I miss from my SVN days. I'm also still using Perforce, which can do even crazier things with workspace mappings.
xxpor 5y ago
As someone raised on git, and is seriously confused/scared every time he has to use svn, I'm not sure what you mean. I use the folder git creates as a repo too?
- williamvds 5y ago
  Per my understanding of SVN, a checkout only downloads the lastest version of all the files ("pristines"). Git on the other hand clones just about everything from the remote repository, giving you a fully-fledged repository locally. SVN operations that need more history like log and blame will communicate with the repository for that info.
  - azornathogron 5y ago
    This isn't example isn't about not copying history (partial clone on the time dimension) it is about not copying the full directory tree but only a subdirectory (partial clone on the spatial dimension).
- afranchuk 5y ago
  The subtlety is that the checkout command as written is checking out only a subdirectory, not the entire repository. Look closely at the given checkout url.
  - xxpor 5y ago
    Ahhhh, that's quite interesting. I could see why that'd be a big deal for a monorepo.

by harvie 5y ago

Gigachad 5y ago

I'm working in hell right now. The current company has the site frontend, backend, and tests in separate repos and it's basically impossible to do anything without force merging because the build is broken without a chicken and egg situation between the 3 pull requests.

laurent123456 5y ago
I worked at a company that not only did that, but also decided to split the main web app into multiple repos, one per country. It was so much fun to do anything in this project.
- xorcist 5y ago
  Now, that's a microservice if there ever was one!
- Iwan-Zotow 5y ago
  that is some good office porno!
hinkley 5y ago
You might want the front end and backend to be compatible across revision numbers, so that’s less of a problem and more of an impedance mismatch with your process. The tests are a trickier problem, in theory you could lock version numbers (the new behavior increments to the new tests) but tests have bugs, and this doesn’t solve two people making behavioral changes at the same time. Short of merging the tests into the respective projects, going full feature toggle for all breaking changes is the only other lever that comes to mind.
- erik_seaberg 5y ago
  This. Deployments and rollbacks are not atomic, so atomic commits do not make frontend+backend breaking changes safe.
- Gigachad 5y ago
  My thinking is that the tests _have_ to be merged with frontend since they do stuff like "Find the button with the content 'continue' and then click it" There is no such thing as backwards compatible changes to button content but yeah you are right, it would be possible to create backwards compatible API changes but I don't know if it's even worth it since we are the only users of the api, and it is only used for the frontend.
  - nitrogen 5y ago
    There is no such thing as backwards compatible changes to button content If your form html is reasonably semantically structured, and/or you give meaningful IDs to each interactive element, then your tests can be made somewhat robust against content changes. E.g. "click button #next-step" rather than "click the word Next". If your frontend is a desktop or mobile app, look for ways to introspect the widget hierarchy to do the same thing (I know this is possible in e.g. Swing).
    - Vinnl 5y ago
      But generally you'll want to emulate how users use your application, which is looking for a button with a particular label (bonus points if your tests are looking for the accessible label), rather than something with a given ID.

williamvds 5y ago

With shallow checkouts cloning is much quicker. You could try combining it with sparse checkouts too. You can even have Git fetch the full history in the background, and from a quick test you can do stuff like commit while it's fetching. Obviously the limited history means commands like log and blame will be inaccurate until it's done. $ git clone --depth=1 <url> $ cd repo $ git fetch --unshallow & $ <do work>

vtbassmatt 5y ago
This is really expensive for the server (the unshallow step specifically). Consider a partial clone here instead.
- williamvds 5y ago
  Is unshallowing any more expensive than a normal clone? The shallow clone is for the benefit of the user so they can get to work sooner.
  - vtbassmatt 5y ago
    It is, because of the way the server has to recompute packfiles. I realize that you may choose to optimize for the user over the server, but a partial (blobless) clone should satisfy both.
    - erik_seaberg 5y ago
      Does the server rule out sending a packfile that you only need 95% of? That seems like a good thing to optimize.

zwieback 5y ago

Yeah, that's really the one thing I miss from my SVN days. I'm also still using Perforce, which can do even crazier things with workspace mappings.

xxpor 5y ago

As someone raised on git, and is seriously confused/scared every time he has to use svn, I'm not sure what you mean. I use the folder git creates as a repo too?

williamvds 5y ago
Per my understanding of SVN, a checkout only downloads the lastest version of all the files ("pristines"). Git on the other hand clones just about everything from the remote repository, giving you a fully-fledged repository locally. SVN operations that need more history like log and blame will communicate with the repository for that info.
- azornathogron 5y ago
  This isn't example isn't about not copying history (partial clone on the time dimension) it is about not copying the full directory tree but only a subdirectory (partial clone on the spatial dimension).
afranchuk 5y ago
The subtlety is that the checkout command as written is checking out only a subdirectory, not the entire repository. Look closely at the given checkout url.
- xxpor 5y ago
  Ahhhh, that's quite interesting. I could see why that'd be a big deal for a monorepo.