Hacker News Reader

Hacker News

Comment by harvie | Hacker News Reader

Full thread

harvie

I hope one day all of this will be as easy as in SVN. eg.:

I have repository https://example.com/myrepo

And i can simply do:

svn co 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.

View on HN

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.

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.

Now, that's a microservice if there ever was one!

that is some good office porno!

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.

This. Deployments and rollbacks are not atomic, so atomic commits do not make frontend+backend breaking changes safe.

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.

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).

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.

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>

This is really expensive for the server (the unshallow step specifically). Consider a partial clone here instead.

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.

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.

Does the server rule out sending a packfile that you only need 95% of? That seems like a good thing to optimize.

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.

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?

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.

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).

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.

Ahhhh, that's quite interesting. I could see why that'd be a big deal for a monorepo.

Reply on news.ycombinator.com